Event ID 231

Event ID 231: Mount Operation Error - Fix Guide 2025

Complete troubleshooting guide for Exchange Event ID 231 mount errors. Fix database mount failures, Active Directory connectivity issues, and permission problems with step-by-step solutions.

Medha Cloud
Medha Cloud Exchange Server Team
Exchange Database Recovery Team8 min read

Table of Contents

Reading Progress
0 of 9

Seeing Event ID 231 when trying to mount your Exchange database? This error indicates that the mount operation failed due to infrastructure, permissions, or configuration issues.

Our Exchange Database Mount Troubleshooting Services team has resolved hundreds of Event ID 231 scenarios across all Exchange versions. This guide provides proven step-by-step solutions to identify the specific cause and restore database access quickly.

📌 Version Compatibility: This guide applies to Exchange Server 2016, Exchange Server 2019, Exchange Server 2022 (SE). Commands may differ for other versions.

Error Overview

Error Message (Event Viewer)
Event ID: 231
Source: MSExchangeIS
Level: Error

The Microsoft Exchange Information Store service was unable to mount
the mailbox database.

Database: Mailbox Database 01
Error: 0x80040115
Additional information: An error occurred while connecting to the
Active Directory domain controller. Verify network connectivity and
domain controller availability.

What Causes This Error?

  • Active Directory Connectivity Issues (30%): Exchange cannot contact domain controllers to read database configuration due to network issues, DC offline, or firewall blocking LDAP/Kerberos traffic.
  • Insufficient Permissions (25%): Exchange service account lacks necessary permissions on database files, Active Directory objects, or registry keys required for mount operations.
  • Service Dependencies Not Running (15%): Exchange Information Store depends on System Attendant, Active Directory Topology, or RPC services. If dependencies are stopped, mount fails with Event ID 231.
  • Database Object Misconfiguration (12%): Database properties in Active Directory are corrupted, mismatched, or point to incorrect servers (common after restores or migrations).
  • Locked or Inaccessible Database Files (10%): Database files are locked by another process (backup software, antivirus), or file system permissions deny Exchange access.
  • Circular Logging Mismatch (8%): Circular logging setting in AD differs from actual database state, preventing Exchange from determining proper recovery mode.

Event ID 231 Common Error Codes

0x80040115
MAPI_E_FAILONEPROVIDER: Cannot connect to Active Directory or read database configuration
-1032
JET_errFileAccessDenied: Insufficient permissions to access database files
-1811
JET_errFileNotFound: Database or log file path is incorrect or files are missing
-546
JET_errDatabaseSharingViolation: Database file is locked by another process (backup, AV)

💡 Pro Tip: The specific error code within Event ID 231 is crucial for diagnosis. Always check the full event details (right-click event → Event Properties → Details tab) to see the underlying error code. Error 0x80040115 means AD connectivity, -1032 means permissions, -546 means file locking. Knowing the exact code immediately points you to the right troubleshooting path.

Quick Fix: Restart Services and Check AD (5 Minutes)

Many Event ID 231 errors are caused by transient service issues or temporary Active Directory connectivity problems. Start with service restart and AD validation before deeper troubleshooting.

Step 1: Check Exchange Service Dependencies
# List Exchange service dependencies and their status
Get-Service MSExchangeIS | Select-Object -ExpandProperty DependentServices |
    Format-Table Name, Status, DisplayName -AutoSize

# These services must be running:
# - MSExchangeADTopology (Active Directory Topology)
# - MSExchangeSA (System Attendant)
# - RpcSs (Remote Procedure Call)
# - EventLog (Windows Event Log)

# Check if any required services are stopped
$RequiredServices = @("MSExchangeADTopology", "MSExchangeSA", "RpcSs", "EventLog")
foreach ($Service in $RequiredServices) {
    $Status = Get-Service $Service
    if ($Status.Status -ne "Running") {
        Write-Host "⚠ $Service is $($Status.Status) - MUST BE RUNNING"$Status.Status) - MUST BE RUNNING" -ForegroundColor Red
        Start-Service $Service
    } else {
        Write-Host "✓ $Service is running" -ForegroundColor Green
    }
}
Step 2: Verify Active Directory Connectivity
# Test connection to domain controllers
nltest /dclist:$env:USERDNSDOMAIN

# Verify Exchange can query Active Directory
Get-ADServerSettings | Format-List

# Test LDAP connectivity to preferred DC
$DC = (Get-ADServerSettings).PreferredGlobalCatalog(0)
Test-NetConnection -ComputerName $DC -Port 389
Test-NetConnection -ComputerName $DC -Port 3268  # Global Catalog

# Check for AD replication delays
repadmin /showrepl | Select-String "error|failed"

# Verify Exchange can read database object from AD
Get-MailboxDatabase "Mailbox Database 01" |
    Format-List Name, Server, EdbFilePath, MountAtStartup
Step 3: Restart Exchange Information Store
# Stop Exchange Information Store service
Stop-Service MSExchangeIS -Force

# Wait for service to fully stop
Start-Sleep -Seconds 10

# Clear any stuck mount operations from previous attempts
# (Optional: restart dependent services to clear state)
Restart-Service MSExchangeADTopology -Force

# Start Exchange Information Store
Start-Service MSExchangeIS

# Wait for service initialization
Start-Sleep -Seconds 30

# Verify service is running
Get-Service MSExchangeIS | Select-Object Name, Status

# Check Event Viewer for service startup events
Get-EventLog -LogName Application -Source MSExchangeIS -Newest 5 |
    Format-Table TimeGenerated, EntryType, Message -AutoSize
Step 4: Attempt Database Mount
# Mount the database
Mount-Database "Mailbox Database 01"

# Wait 30 seconds for mount operation
Start-Sleep -Seconds 30

# Verify mount succeeded
Get-MailboxDatabase "Mailbox Database 01" |
    Format-List Name, Mounted, Server, DatabaseSize

# If mounted = True, quick fix succeeded
# If still False, check Event Viewer for new Event ID 231 with specific error code

✅ Success Indicator: If the database mounts after service restart and shows "Mounted: True," the issue was a transient service or AD connectivity problem. Monitor for 24 hours to ensure mount remains stable. If Event ID 231 recurs, proceed to Advanced Troubleshooting to address the root cause.

Verify the Fix

Comprehensive Mount Verification Checks
# 1. Verify database is mounted
Get-MailboxDatabase "Mailbox Database 01" |
    Select-Object Name, Mounted, Server, Mounted, DatabaseSize

# 2. Test mailbox connectivity
Test-MAPIConnectivity -Database "Mailbox Database 01"

# 3. Check Event Viewer for mount success
Get-EventLog -LogName Application -Source MSExchangeIS -Newest 10 |
    Where-Object { $_.Message -like "*Mailbox Database 01*" } |
    Select-Object TimeGenerated, EntryType, Message

# Look for Event ID 1120: "Database mounted successfully""Database mounted successfully"
# Ensure no new Event ID 231 errors

# 4. Verify AD connectivity remains stable
$DC = (Get-ADServerSettings).PreferredGlobalCatalog(0)
Test-NetConnection -ComputerName $DC -Port 389 -WarningAction SilentlyContinue

# 5. Confirm all Exchange services are running
Get-Service MSExchange* | Where-Object { $_.Status -ne "Running" } |
    Format-Table Name, Status, DisplayName

# 6. Test user mailbox access
Get-Mailbox -Database "Mailbox Database 01" -ResultSize 5 |
    ForEach-Object { Test-Mailbox $_.Alias } |
    Format-Table Identity, LatencyInMilliseconds, Result

Expected Results After Successful Mount

  • Database shows "Mounted: True" with no errors in Event Viewer
  • Event ID 1120 ("Database mounted successfully") appears in Application log
  • Test-MAPIConnectivity succeeds for all mailboxes
  • LDAP connectivity to domain controllers remains stable (ports 389/3268)
  • All Exchange services remain in "Running" state
  • Users can access mailboxes via Outlook, OWA, and mobile devices without errors

Advanced Troubleshooting

If service restart doesn't resolve Event ID 231, use the specific error code to target the root cause. Each error code requires a different troubleshooting approach.

Scenario 1: Error 0x80040115 - Active Directory Connectivity Failure

This error means Exchange cannot reach a domain controller or read the database object from Active Directory. Network issues, DC offline, or DNS problems are common causes.

Diagnose and Fix AD Connectivity Issues
# 1. Identify which domain controller Exchange is using
Get-ADServerSettings | Format-List PreferredGlobalCatalog, ConfigurationDomainController

# 2. Test connectivity to the DC
$DC = (Get-ADServerSettings).PreferredGlobalCatalog(0)
Test-NetConnection -ComputerName $DC -Port 389  # LDAP
Test-NetConnection -ComputerName $DC -Port 3268 # Global Catalog
Test-NetConnection -ComputerName $DC -Port 88   # Kerberos

# 3. Verify DNS resolution for DC
Resolve-DnsName $DC

# 4. Check if DC is reachable via ping
ping $DC

# 5. If DC is offline or unreachable, reset AD connection
# Force Exchange to discover new domain controllers
Set-ADServerSettings -ResetAllSettings
Restart-Service MSExchangeADTopology -Force
Start-Sleep -Seconds 30

# 6. Verify new DC discovery
Get-ADServerSettings | Format-List

# 7. Check domain controller health on the DC itself (if accessible)
# Run on domain controller:
dcdiag /v
repadmin /showrepl

# 8. If DNS issues, flush DNS cache and re-register-register
ipconfig /flushdns
ipconfig /registerdns

# 9. Attempt mount after AD connectivity restored
Mount-Database "Mailbox Database 01"

Scenario 2: Error -1032 - Insufficient Permissions

JET_errFileAccessDenied indicates the Exchange service account lacks permissions to access database files, registry keys, or Active Directory objects.

Fix Exchange Service Account Permissions
# 1. Identify Exchange service account
$ServiceAccount = (Get-WmiObject Win32_Service -Filter "Name='MSExchangeIS'").StartName
Write-Host "Exchange IS runs as: $ServiceAccount" -ForegroundColor Yellow

# 2. Check database file permissions
$DBPath = (Get-MailboxDatabase "Mailbox Database 01").EdbFilePath.PathName
$DBFolder = Split-Path $DBPath
icacls $DBFolder

# 3. Grant Exchange service account full control on database folder
$Acl = Get-Acl $DBFolder
$Permission = New-Object System.Security.AccessControl.FileSystemAccessRule(
    $ServiceAccount, "FullControl", "ContainerInherit,ObjectInherit", "None", "Allow"
)
$Acl.SetAccessRule($Permission)
Set-Acl -Path $DBFolder -AclObject $Acl

# 4. Verify Exchange has permissions on transaction log folder
$LogPath = (Get-MailboxDatabase "Mailbox Database 01").LogFolderPath.PathName
icacls $LogPath
# Repeat ACL grant for log folder if needed

# 5. Reset Exchange service account permissions (if corrupted)
# Re-run Exchange setup in RecoverServer mode to reset all permissions
# (This requires downtime and should be last resort)

# 6. Check Active Directory permissions on database object
$DB = Get-MailboxDatabase "Mailbox Database 01"
$DN = $DB.DistinguishedName
dsacls $DN

# 7. Restart services to apply permission changes
Restart-Service MSExchangeIS -Force
Start-Sleep -Seconds 30

# 8. Attempt mount
Mount-Database "Mailbox Database 01"

💡 Pro Tip: After granting file permissions, always restart MSExchangeIS to ensure the service picks up new ACLs. Windows caches security tokens, so permission changes don't apply to already-running processes. The service must be restarted to obtain a new token with updated permissions.

Scenario 3: Error -546 - Database File Locked by Another Process

JET_errDatabaseSharingViolation means another process (backup software, antivirus, disk utility) has an exclusive lock on the database file, preventing Exchange from accessing it.

Identify and Release File Lock
# 1. Use Sysinternals Handle tool to identify process locking file
# Download Handle.exe from https://learn.microsoft.com/sysinternals
# Run as administrator:
handle.exe "DB01.edb"

# Output shows process ID (PID) and process name holding lock
# Example: "veeam.exe pid: 3456"

# 2. Alternative: Use Process Explorer (GUI tool)
# procexp.exe → Find → Handle or DLL → Search for "DB01.edb"

# 3. Identify the locking process
$DBPath = (Get-MailboxDatabase "Mailbox Database 01").EdbFilePath.PathName
Get-Process | Where-Object { $_.Modules.FileName -eq $DBPath }

# 4. If backup software is locking file, stop backup service
# Example for Veeam:
Stop-Service VeeamBackupSvc -Force

# 5. If antivirus is locking file, temporarily disable real-time scanning-time scanning
# Then add permanent AV exclusions for Exchange paths:
Add-MpPreference -ExclusionPath "D:\ExchangeDBs\"
Add-MpPreference -ExclusionExtension "-ExclusionExtension ".edb"
Add-MpPreference -ExclusionExtension "-ExclusionExtension ".log"

# 6. Restart Exchange Information Store
Restart-Service MSExchangeIS -Force
Start-Sleep -Seconds 30

# 7. Attempt mount
Mount-Database "Restart-Service MSExchangeIS -Force
Start-Sleep -Seconds 30

# 7. Attempt mount
Mount-Database "Mailbox Database 01"

# 8. After successful mount, restart backup service
Start-Service VeeamBackupSvc

Scenario 4: Database Object Misconfiguration in Active Directory

If the database object in Active Directory has incorrect settings (wrong server, invalid path, corrupted attributes), Event ID 231 can occur even when the database file is healthy.

Validate and Repair Database Configuration
# 1. Check database configuration in Active Directory
Get-MailboxDatabase "Mailbox Database 01" |
    Format-List Name, Server, EdbFilePath, LogFolderPath, CircularLoggingEnabled, MountAtStartup

# 2. Verify Server attribute matches current server
$DB = Get-MailboxDatabase "Mailbox Database 01"
if ($DB.Server.Name -ne $env:COMPUTERNAME) {
    Write-Host "⚠ Database Server attribute ($($DB.Server.Name)) does not match current server ($env:COMPUTERNAME)"$env:COMPUTERNAME)" -ForegroundColor Red
    # This happens after restoring database to different server
}

# 3. Update database server association if needed (after restore/migration)
Set-MailboxDatabase "Mailbox Database 01" -Server $env:COMPUTERNAME

# 4. Verify paths are correct and files exist
$EdbPath = $DB.EdbFilePath.PathName
$LogPath = $DB.LogFolderPath.PathName

Test-Path $EdbPath  # Should be True
Test-Path $LogPath  # Should be True

# 5. Check for duplicate database objects in AD
Get-MailboxDatabase | Where-Object { $_.Name -eq "Mailbox Database 01" } |
    Format-Table Name, DistinguishedName, Server

# If duplicates exist, delete the invalid one:
# Remove-MailboxDatabase "CN=Mailbox Database 01,CN=Databases,CN=Exchange Administrative Group...""CN=Mailbox Database 01,CN=Databases,CN=Exchange Administrative Group..."

# 6. Force AD replication to propagate changes
repadmin /syncall /AeD

# 7. Restart Exchange services to pick up new config
Restart-Service MSExchangeIS -Force
Start-Sleep -Seconds 30

# 8. Attempt mount
Mount-Database "Mailbox Database 01"

Prevention

Prevent Event ID 231 Mount Errors

  • Monitor Domain Controller Health: Use dcdiag and repadmin weekly to check AD replication status. Exchange mount failures often correlate with DC downtime or replication delays. Ensure all Exchange servers have fast, reliable connections to at least two DCs.
  • Implement Backup Software Best Practices: Configure backup applications to use VSS-aware Exchange snapshots rather than file-level locks. Schedule backups during maintenance windows when database mounts are not expected. Test backup jobs to ensure they release file locks properly after completion.
  • Maintain Correct Antivirus Exclusions: Follow Microsoft guidelines for Exchange AV exclusions. Exclude .edb, .log, .chk files, and Exchange install directories. Real-time scanning on database files is a leading cause of file locking issues that present as Event ID 231.
  • Document Database-to-Server Mappings: Keep an inventory of which databases reside on which servers, especially in multi-server environments. After restores or migrations, always verify the database's Server attribute in AD matches the actual hosting server using Get-MailboxDatabase.
  • Test Mount Operations After Maintenance: After Windows Updates, Exchange CUs, storage changes, or DC maintenance, manually test database mounts before user access windows. Run Dismount-Database then Mount-Database to validate mount process integrity.
Automated Mount Health Check Script
# Save as Check-ExchangeMountHealth.ps1
# Schedule with Task Scheduler to run every 4 hours

$Results = @()

# Check all databases on local server
$Databases = Get-MailboxDatabase -Server $env:COMPUTERNAME

foreach ($DB in $Databases) {
    # Check mount status
    if (-not $DB.Mounted) {
        $Results += "CRITICAL: Database $($DB.Name) is DISMOUNTED"
    }

    # Check AD connectivity
    try {
        $ADTest = Get-ADServerSettings -ErrorAction Stop
        if (-not $ADTest) {
            $Results += "ERROR: Cannot connect to Active Directory"
        }
    } catch {
        $Results += "ERROR: AD connectivity failed - $($_.Exception.Message)"
    }

    # Check service dependencies
    $Services = @("MSExchangeIS", "MSExchangeADTopology", "MSExchangeSA")
    foreach ($Service in $Services) {
        $Status = Get-Service $Service -ErrorAction SilentlyContinue
        if ($Status.Status -ne "Running") {
            $Results += "WARNING: Service $Service is $($Status.Status)"$Status.Status)"
        }
    }

    # Check for recent Event ID 231 errors
    $RecentErrors = Get-EventLog -LogName Application -Source MSExchangeIS \
        -After (Get-Date).AddHours(-4) -ErrorAction SilentlyContinue |
        Where-Object { $_.EventID -eq 231 }

    if ($RecentErrors.Count -gt 0) {
        $Results += "ALERT: $($RecentErrors.Count) Event ID 231 mount errors in last 4 hours"231 mount errors in last 4 hours"
    }

    # Test MAPI connectivity
    try {
        $MapiTest = Test-MAPIConnectivity -Database $DB.Name -ErrorAction Stop
        if ($MapiTest.Result -ne "Success") {
            $Results += "WARNING: MAPI connectivity test failed for $($DB.Name)"
        }
    } catch {
        $Results += "ERROR: Cannot test MAPI connectivity for $($DB.Name)"
    }
}

# Send alert if issues found
if ($Results.Count -gt 0) {
    $Body = "Exchange Mount Health Issues Detected:\n\n" + ($Results -join "\n")
    Send-MailMessage \
        -To "admin@company.com" \
        -From "exchange-monitor@company.com" \
        -Subject "Exchange Mount Health Alert - $($Results.Count) Issues" \
        -Body $Body \
        -SmtpServer "smtp.company.com"
} else {
    Write-Host "✓ All mount health checks passed" -ForegroundColor Green
}

When to Escalate: Stop Troubleshooting

Event ID 231 Persisting After Service Restarts?

If you've restarted services, verified AD connectivity, checked permissions, and released file locks but Event ID 231 continues, you likely have complex Active Directory issues, database object corruption, or infrastructure problems requiring advanced diagnostics.

Our Database Mount Troubleshooting Service Includes:

  • Advanced Active Directory diagnostics (LDAP tracing, Kerberos authentication analysis)
  • Database object validation and repair in Active Directory configuration partition
  • Permission auditing across file system, registry, and Active Directory objects
  • Service dependency analysis to identify hidden configuration issues
  • Network tracing to diagnose intermittent DC connectivity problems
  • Complete mount workflow analysis from service startup through successful mount
Start Database Mount Troubleshooting

Average Response Time: 15 Minutes • 24/7 Emergency Hotline Available

Frequently Asked Questions

Event ID 231 indicates that Exchange encountered an error while attempting to mount a mailbox database. The error message typically includes an underlying error code (like -1018, -1032, or -1032) that identifies the specific reason for mount failure. Common causes include Active Directory connectivity issues, insufficient permissions, database file problems, or service dependencies not running.

Can't Resolve Event ID 231?

Exchange errors can cause data loss or extended downtime. Our specialists are available 24/7 to help.

Emergency help - Chat with us
Medha Cloud

Medha Cloud Exchange Server Team

Microsoft Exchange Specialists

Our Exchange Server specialists have 15+ years of combined experience managing enterprise email environments. We provide 24/7 support, emergency troubleshooting, and ongoing administration for businesses worldwide.

15+ Years ExperienceMicrosoft Certified99.7% Success Rate24/7 Support