Error 0x8004010f

Error 0x8004010f: Database Not Found - Fix Guide 2025

Complete troubleshooting guide for Exchange error 0x8004010f (MAPI_E_NOT_FOUND). Fix database path issues, missing EDB files, and registry mismatches 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

Encountering error 0x8004010f when trying to mount your Exchange database? This MAPI error (MAPI_E_NOT_FOUND) indicates that Exchange cannot locate the database file at the configured path.

Our Exchange Database Recovery Services team has resolved hundreds of database path mismatches across all Exchange versions. This guide provides proven step-by-step solutions to quickly restore database access without data loss.

📌 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: 9519
Source: MSExchangeIS
Level: Error

Failed to mount database "Mailbox Database 01".
Error: MapiExceptionNotFound: Unable to mount database.
(hr=0x8004010f, ec=-2147221233)

Additional information: The database file could not be found at
the specified path: D:\ExchangeDBs\DB01\DB01.edb

What Causes This Error?

  • Database File Moved (35%): The .edb file was manually moved to a different location (new drive, folder restructure) but Exchange configuration still points to the old path.
  • Incorrect Path Configuration (25%): Database path was incorrectly set during creation or migration, pointing to a non-existent location.
  • Drive Letter Changed (20%): Storage reconfiguration (SAN migration, drive reassignment) changed the drive letter where the database resides.
  • Database File Deleted (10%): Accidental deletion of the .edb file or entire database folder without proper decommissioning.
  • Network Path Issues (5%): Database stored on network share (unsupported configuration) and share is unavailable or path is broken.
  • Permissions Issue (5%): Exchange service account lacks permissions to access the database path, causing file system to report "not found."

Database Path Mismatch Flow

Exchange Config
EdbFilePath: D:\DB01\DB01.edb
Actual Location
E:\NewDB\DB01.edb
Error 0x8004010f
Database Not Found
⬇️ Solution: Update configuration or move file
Option 1: Update Path
Set-MailboxDatabase -EdbFilePath
OR
Option 2: Move File
Copy .edb to expected path

💡 Pro Tip: Before moving database files or updating paths, run Get-MailboxDatabase | Format-List Name, EdbFilePath, LogFolderPath to see exactly where Exchange expects to find files. Then use Test-Path to verify if files actually exist at those locations. This 30-second check instantly identifies path mismatches.

Quick Fix: Update Database Path (5 Minutes)

If you know where the database file actually is, the fastest fix is to update Exchange configuration to point to the correct location. This does not modify the database or cause data loss.

Step 1: Identify Path Mismatch
# Get configured database path
$DB = Get-MailboxDatabase "Mailbox Database 01"
$ConfiguredPath = $DB.EdbFilePath.PathName
$ConfiguredLogPath = $DB.LogFolderPath.PathName

Write-Host "Exchange expects database at: $ConfiguredPath" -ForegroundColor Yellow
Write-Host "Exchange expects logs at: $ConfiguredLogPath" -ForegroundColor Yellow

# Check if files exist at configured paths
if (Test-Path $ConfiguredPath) {
    Write-Host "✓ Database file FOUND at configured path" -ForegroundColor Green
} else {
    Write-Host "✗ Database file NOT FOUND at configured path" -ForegroundColor Red
}

# Search for database file in common locations
$SearchPaths = @("D:\", "E:\", "C:\Program Files\Microsoft\Exchange Server\")
foreach ($Path in $SearchPaths) {
    $Found = Get-ChildItem -Path $Path -Filter "$SearchPaths) {
    $Found = Get-ChildItem -Path $Path -Filter "*.edb" -Recurse -ErrorAction SilentlyContinue |
        Where-Object { $_.Name -eq $DB.Name + "-ErrorAction SilentlyContinue |
        Where-Object { $_.Name -eq $DB.Name + ".edb" }
    if ($Found) {
        Write-Host "-Host "✓ Database found at: $($Found.FullName)" -ForegroundColor Green
    }
}
Step 2: Update Database Path Configuration
# Dismount the database first (required before path change)
Dismount-Database "Mailbox Database 01" -Confirm:$false

# Update database file path to actual location
# Replace with your actual path where the .edb file exists
Set-MailboxDatabase "Mailbox Database 01" \
    -EdbFilePath "E:\NewDB\DB01\DB01.edb"

# Update log folder path if logs were also moved
Set-MailboxDatabase "Mailbox Database 01" \
    -LogFolderPath "E:\NewDB\DB01"

# Verify new paths are set correctly
Get-MailboxDatabase "Mailbox Database 01" |
    Format-List Name, EdbFilePath, LogFolderPath
Step 3: Mount Database with New Path
# Force AD replication to propagate path change
repadmin /syncall /AeD

# Wait 30 seconds for replication
Start-Sleep -Seconds 30

# Restart Exchange Information Store service to pick up new config
Restart-Service MSExchangeIS -Force

# Wait for service to initialize
Start-Sleep -Seconds 30

# Mount the database
Mount-Database "Mailbox Database 01"

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

✅ Success Indicator: If Get-MailboxDatabase shows "Mounted: True" and the EdbFilePath reflects your new location, the path update succeeded. Users should now be able to access their mailboxes immediately.

Verify the Fix

Comprehensive Verification Checks
# 1. Verify database is mounted at new path
Get-MailboxDatabase "Mailbox Database 01" |
    Format-Table Name, Mounted, EdbFilePath, LogFolderPath -AutoSize

# 2. Confirm file system paths match configuration
$DB = Get-MailboxDatabase "Mailbox Database 01"
$EdbPath = $DB.EdbFilePath.PathName
$LogPath = $DB.LogFolderPath.PathName

Write-Host "Checking file existence..."
Test-Path $EdbPath  # Should return True
Get-ChildItem $LogPath -Filter "*.log"  # Should list log files

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

# 4. 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

# 5. Verify users can access mailboxes
Get-Mailbox -Database "Mailbox Database 01" -ResultSize 5 |
    ForEach-Object { Test-Mailbox $_.Alias }

Expected Results After Successful Path Update

  • Database shows "Mounted: True" with correct EdbFilePath
  • Test-Path confirms .edb file exists at configured path
  • Transaction logs (.log files) are in the configured LogFolderPath
  • Test-MAPIConnectivity returns success for all mailboxes
  • Event Viewer shows "Database mounted successfully" (Event ID 1120)
  • Users can send/receive email through Outlook, OWA, and ActiveSync

Advanced Troubleshooting

If updating the path doesn't resolve the error, or you need to physically move database files to a new location, follow these advanced scenarios.

Scenario 1: Move Database Files to New Location (Supported Method)

If you need to move the database to a different drive or folder (SAN migration, storage consolidation), use the supported Move-DatabasePath cmdlet which handles all file movement and configuration updates automatically.

Supported Database Move (Zero Risk)
# This cmdlet moves both .edb and .log files, updates config, and remounts
Move-DatabasePath "Mailbox Database 01" \
    -EdbFilePath "E:\ExchangeDBs\DB01\DB01.edb" \
    -LogFolderPath "E:\ExchangeDBs\DB01" \
    -ConfigurationOnly:$false \
    -Confirm:$false

# The cmdlet performs these steps automatically:
# 1. Dismounts database
# 2. Copies .edb file to new location
# 3. Moves all .log files to new location
# 4. Updates AD configuration
# 5. Remounts database

# Verify move completed successfully
Get-MailboxDatabase "Mailbox Database 01" |
    Format-List Name, Mounted, EdbFilePath, LogFolderPath

💡 Pro Tip: Move-DatabasePath is the safest way to relocate Exchange databases. It handles all file operations, ensures transaction log integrity, updates configuration in a single atomic operation, and automatically validates the new location before committing. Always use this cmdlet instead of manual file copying.

Scenario 2: Database File Accidentally Deleted - Restore from Backup

If the .edb file was accidentally deleted and is unrecoverable (not in Recycle Bin, no shadow copies), you must restore from backup. Do not attempt to create a new blank database with the same name—this causes mailbox data loss.

Restore Database from Windows Server Backup
# 1. Check available backups
wbadmin get versions -backupTarget:E:

# 2. Restore database files to temporary location
# Replace version identifier with your actual backup timestamp
wbadmin start recovery -version:12/01/2025-00:00 \
    -itemType:File \
    -items:"D:\ExchangeDBs\DB01\DB01.edb" \
    -recoverytarget:"D:\TempRestore" \
    -notRestoreAcl

# 3. Stop Exchange Information Store
Stop-Service MSExchangeIS -Force

# 4. Copy restored database to correct location
Copy-Item "D:\TempRestore\DB01.edb" -Destination "D:\ExchangeDBs\DB01\DB01.edb"

# 5. Check database state
ESEUTIL /MH "D:\ExchangeDBs\DB01\DB01.edb" | Select-String "State"

# 6. If backup was taken with VSS, database should be in clean state
# Start Exchange and mount
Start-Service MSExchangeIS
Start-Sleep -Seconds 30
Mount-Database "Mailbox Database 01"

Scenario 3: Drive Letter Changed After SAN Migration

If storage was reconfigured (SAN migration, disk reallocation) and the drive letter changed from D: to E:, simply update the database path without moving files.

Update Path After Drive Letter Change
# Example: Database was on D:\ but drive is now E:\
# Files are physically in the same place, just different drive letter

# 1. Verify files exist at new drive letter
Test-Path "E:\ExchangeDBs\DB01\DB01.edb"
Get-ChildItem "E:\ExchangeDBs\DB01" -Filter "*.log"

# 2. Dismount database
Dismount-Database "Mailbox Database 01" -Confirm:$false

# 3. Update path to reflect new drive letter
Set-MailboxDatabase "Mailbox Database 01" \
    -EdbFilePath "E:\ExchangeDBs\DB01\DB01.edb" \
    -LogFolderPath "E:\ExchangeDBs\DB01"

# 4. Force AD replication and restart service
repadmin /syncall /AeD
Restart-Service MSExchangeIS -Force
Start-Sleep -Seconds 30

# 5. Mount database
Mount-Database "Mailbox Database 01"

Scenario 4: Permissions Issue - Exchange Cannot Access Database Path

Sometimes error 0x8004010f is actually a permissions problem disguised as a "not found" error. The file exists, but the Exchange service account cannot read it.

Fix Database File 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 current permissions on database folder
$DBPath = "D:\ExchangeDBs\DB01"
Get-Acl $DBPath | Format-List

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

# 4. Verify permissions were applied
icacls $DBPath

# 5. Restart Exchange Information Store and mount
Restart-Service MSExchangeIS -Force
Start-Sleep -Seconds 30
Mount-Database "Mailbox Database 01"

Prevention

Prevent Database Path Errors

  • Always Use Move-DatabasePath Cmdlet: Never manually move .edb files using File Explorer or robocopy. Use Move-DatabasePath which updates configuration atomically and ensures log file integrity. Manual moves break the configuration linkage.
  • Document Drive Mappings: Maintain documentation of which databases reside on which drives/paths. Before SAN migrations or storage reconfigurations, audit all Exchange database paths with Get-MailboxDatabase | Format-Table Name, EdbFilePath.
  • Use Consistent Drive Letters: Standardize on specific drive letters for Exchange databases (e.g., E: for databases, F: for logs) across all servers. Configure SAN/storage systems to maintain these drive assignments during failovers or migrations.
  • Monitor AD Replication: After any database path changes, verify AD replication completed with repadmin /showrepl. Stale AD data can cause Exchange to use old paths even after updates.
  • Implement Change Control: Require approval and documentation before any database moves. Include validation steps (Test-Path checks, mount verification) in your change procedures. Test path updates in non-production environments first.
Database Path Validation Script (Run Before Migrations)
# Save as Validate-ExchangeDatabasePaths.ps1
# Run before SAN migrations or storage changes

$Databases = Get-MailboxDatabase -Server $env:COMPUTERNAME

foreach ($DB in $Databases) {
    $EdbPath = $DB.EdbFilePath.PathName
    $LogPath = $DB.LogFolderPath.PathName

    Write-Host "\n========================================" -ForegroundColor Cyan
    Write-Host "Database: $($DB.Name)" -ForegroundColor Cyan
    Write-Host "========================================" -ForegroundColor Cyan

    # Check .edb file
    if (Test-Path $EdbPath) {
        $FileInfo = Get-Item $EdbPath
        Write-Host "✓ EDB File Found: $EdbPath" -ForegroundColor Green
        Write-Host "  Size: $([math]::Round($FileInfo.Length / 1GB, 2)) GB"2)) GB" -ForegroundColor Gray
        Write-Host "  Last Modified: $($FileInfo.LastWriteTime)" -ForegroundColor Gray
    } else {
        Write-Host "✗ EDB File NOT FOUND: $EdbPath" -ForegroundColor Red
        Write-Host "  ACTION REQUIRED: Locate database or restore from backup" -ForegroundColor Yellow
    }

    # Check log files
    $LogFiles = Get-ChildItem $LogPath -Filter "*.log" -ErrorAction SilentlyContinue
    if ($LogFiles) {
        Write-Host "✓ Log Files Found: $($LogFiles.Count) files in $LogPath"$LogPath" -ForegroundColor Green
    } else {
        Write-Host "✗ No log files found in: $LogPath" -ForegroundColor Red
    }

    # Check mount status
    $Status = Get-MailboxDatabase $DB.Name | Select-Object -ExpandProperty Mounted
    if ($Status) {
        Write-Host "✓ Database is currently MOUNTED" -ForegroundColor Green
    } else {
        Write-Host "⚠ Database is currently DISMOUNTED" -ForegroundColor Yellow
    }
}

Write-Host "\n========================================" -ForegroundColor Cyan
Write-Host "Validation Complete" -ForegroundColor Cyan
Write-Host "========================================" -ForegroundColor Cyan

When to Escalate: Stop Troubleshooting

Still Seeing Error 0x8004010f After Path Updates?

If you've verified the database file exists at the configured path, updated EdbFilePath, forced AD replication, and restarted services but still get error 0x8004010f, you likely have Active Directory corruption or database configuration inconsistencies requiring advanced diagnostics.

Our Database Configuration Recovery Service Includes:

  • Active Directory configuration validation and repair for Exchange database objects
  • Registry analysis to detect mismatches between AD and local Exchange configuration
  • Database object recreation while preserving mailbox data and user associations
  • Path configuration audits across multi-server DAG environments
  • Permissions troubleshooting for Exchange service accounts and file system access
  • Post-recovery mount testing and mailbox connectivity verification
Start Database Configuration Recovery

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

Frequently Asked Questions

Error 0x8004010f (MAPI_E_NOT_FOUND) means Exchange cannot locate the database file (.edb) at the path specified in Active Directory or the database configuration. This typically occurs when the database file has been moved, deleted, or the path configuration is incorrect. Exchange looks for the database at the configured path and fails when it cannot find the file.

Can't Resolve Error 0x8004010f?

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