Veeam Explorer for Microsoft Exchange: ese.dll, Dirty Shutdown and permission errors

Veeam Explorer for Microsoft Exchange restores items, folders or whole mailboxes from a Veeam backup without touching your production databases. It reads the backed-up .edb with Microsoft's own database engine, so most failures come from three places: the wrong ese.dll, a database copy that still needs its logs replayed, and missing rights on the target mailbox. In this post I'll fix each one and show the native fallback, a recovery database, for when Explorer can't help.

Symptoms#

• Explorer can't open a database you added, and the Extensible Storage Engine (ese.dll) path in its options is empty or belongs to another Exchange version.
• A database added from a file-level restore is reported as dirty, and eseutil /mh on that copy shows:

State: Dirty Shutdown
Log Required: 4512-4519 (0x11a0-0x11a7)

• Tools that open the file directly fail with JET_errDatabaseDirtyShutdown (-550): "Database was not shutdown cleanly. Recovery must first be run to properly complete database operations for the previous shutdown."
• A store from a lagged DAG copy takes a very long time to open.
• Restoring into a mailbox fails with an access or impersonation error. When the restore account relies on impersonation without the role, Exchange Web Services (EWS) answers:

ErrorImpersonateUserDenied: The account does not have permission to impersonate the requested user.

Why it happens#

Explorer works on the database files inside the backup, not on your Exchange servers:

• It needs ese.dll from Exchange, the same version as the Exchange that created the database. For backups made with application-aware processing Explorer finds it automatically; for a database you add by hand, you point Explorer at it.
• A backed-up database is normally "dirty". VSS captures the .edb while it's mounted, so its header says Dirty Shutdown and the transactions in the logs captured with it must be replayed. Explorer replays them when it opens the store, which is why lagged copies with days of logs are slow. For a database added manually, Veeam's guide to adding Exchange databases says to click Recover to apply the logs, then re-add it; the account needs write permission. That fails if the logs weren't backed up (an excluded log disk), the log folder is wrong, or a log is damaged.
• Restores into a live mailbox connect to the target server's Client Access services (the restore wizard asks for a CAS server) as the restore account. Without Full Access on that mailbox, or the ApplicationImpersonation role that lets an account impersonate users through EWS, Exchange refuses.

How to fix it#

1. Give Explorer the matching ese.dll#

In Veeam Explorer open main menu › General Options › Extensible Storage Engine, click the link next to the Exchange version and browse to ese.dll. Take it from the server that hosted the database, or one on the same build:

Get-ExchangeServer EX01 | Format-List Name, AdminDisplayVersion
(Get-Item (Join-Path $env:ExchangeInstallPath 'Bin\ese.dll')).VersionInfo.FileVersion

The Exchange setup media also carries it under \Setup\ServerRoles\Common\ese.dll. Keep a copy for each Exchange version you protect, and refresh it after cumulative updates.

2. Bring a dirty database to Clean Shutdown#

For a store Explorer opens from the backup, let it replay the logs. For one you added by hand, click Recover and make sure the logs folder is the one restored with the database. If Recover keeps failing, check the restored copy yourself (never production) on an Exchange server of the same version, since eseutil ships with Exchange:

eseutil /mh "R:\Restore\DB01.edb"
eseutil /ml "R:\Restore\Logs\E00"
eseutil /r E00 /l "R:\Restore\Logs" /d "R:\Restore"
eseutil /mh "R:\Restore\DB01.edb"

Every log in the Log Required range must be present and /ml must report no damaged logs. After soft recovery the header reads State: Clean Shutdown; add that copy with Home › Add Store › Microsoft Exchange mailbox database. If logs are missing, use an older restore point rather than eseutil /p, which throws data away. My Dirty Shutdown guide explains the header fields.

3. Grant the right permissions#

Veeam's permissions page sets two layers:

• To run Explorer: local administrator on the machine running it, plus the Backup Administrator or Restore Operator role on the backup server (or a custom role with the Manage restores permission).
• To restore into Exchange: Full Access on the target mailbox for an account that owns a mailbox, or the ApplicationImpersonation role for one that doesn't; public folder restores also need Organization Management membership.

Add-MailboxPermission -Identity jane@contoso.com -User svc-veeam-restore -AccessRights FullAccess -InheritanceType All -AutoMapping $false
New-ManagementRoleAssignment -Name "Veeam restore impersonation" -Role ApplicationImpersonation -User svc-veeam-restore

Microsoft retired ApplicationImpersonation in Exchange Online, but Exchange Server still uses it. Allow for AD replication before retrying; if ErrorImpersonateUserDenied persists or EWS throttles a large restore, see EWS errors on Exchange Server.

4. When Explorer can't help: use a recovery database#

Exchange's own route works with any backup. Restore the .edb and logs to a spare volume on a Mailbox server running the same Exchange version, bring the database to Clean Shutdown as above, then:

New-MailboxDatabase -Recovery -Name RDB01 -Server EX01 -EdbFilePath "R:\Restore\DB01.edb" -LogFolderPath "R:\Restore\Logs"
Mount-Database RDB01
Get-MailboxStatistics -Database RDB01 | Format-Table DisplayName, ItemCount, MailboxGuid -AutoSize
New-MailboxRestoreRequest -SourceDatabase RDB01 -SourceStoreMailbox <MailboxGuid> -TargetMailbox jane@contoso.com -TargetRootFolder "Recovered" -AllowLegacyDNMismatch
Get-MailboxRestoreRequest | Get-MailboxRestoreRequestStatistics

Microsoft notes that a recovery database can't hold a database from an earlier Exchange version, and the target mailbox must be in the same Active Directory forest. Dismount and remove the RDB, then delete its files, when you're done.

Verify the fix#

• Explorer opens the store and lists its mailboxes.
• A test item restored to a test mailbox lands in the expected folder with its dates and attachments intact.
• For the RDB route, the restore request shows Completed and the items appear under the target root folder.
• Temporary Full Access or impersonation assignments you no longer need are removed.

Prevent it next time#

• Keep application-aware processing on and every database and log disk in the job; see Veeam application-aware processing errors.
• Keep ese.dll copies with your restore runbook and a pre-approved restore account with scoped rights.
• Test an item restore after every Exchange CU or Veeam upgrade, not during an incident.
• For fast restores, prefer a backup of a non-lagged copy.

References#

• Extensible Storage Engine: Veeam Explorer for Microsoft Exchange (Veeam Help Center)
• Permissions: Veeam Explorer for Microsoft Exchange (Veeam Help Center)
• Backup, restore, and disaster recovery in Exchange Server: recovery databases (Microsoft Learn)