Veeam Backup & Replication with Exchange Server: VSS writer errors and logs not truncating

Veeam Backup & Replication protects Exchange VMs with application-aware processing: it drives the Microsoft Exchange Writer through VSS, snapshots the VM inside a short freeze window and lets Exchange truncate its logs when the backup succeeds. When that chain breaks you get a VSS error in the job log or, worse, a green job and a filling log disk. In this post I'll map the Veeam messages to the Exchange side, fix the usual causes and show how to prove truncation works.

Symptoms#

Veeam's KB1680 documents this failure for Exchange VMs, with the cause line VSSControl: Failed to freeze guest, wait timeout:

Unfreeze error:[Backup job failed] Cannot create shadow copy of the volumes containing writer's data
A VSS critical writer has failed. Writer name: [Microsoft Exchange Writer].
Class ID: [{76fe1ac4-15f7-4bcd-987e-8e1acb462fb7}]. Instance ID: [{...}].
Writer's state: [VSS_WS_FAILED_AT_FREEZE]. Error code: [0x800423f2].]

Admins in Veeam's forums also report this one at the end of the job, often as a warning:

VSS: Backup job failed.
Cannot notify writers about the 'BACKUP FINISH' event.
A VSS critical writer has failed. Writer name: [Microsoft Exchange Writer].
Class ID: [{76fe1ac4-15f7-4bcd-987e-8e1acb462fb7}]. Instance ID: [{...}].
Writer's state: [VSS_WS_FAILED_AT_BACKUP_COMPLETE]. Error code: [0x800423f3].

Other signs: vssadmin list writers in the guest shows the Exchange writer failed or with Last error: Retryable error; transaction logs keep growing behind green jobs; or DAG databases fail over during the backup window.

Why it happens#

With application-aware processing on, Veeam is the VSS requester inside the guest. It asks VSS to freeze the writers (including the Microsoft Exchange Writer, hosted by the Exchange Replication service), triggers the VM snapshot, thaws the writers and, once the backup has been created successfully, reports success so that Exchange truncates its own logs. Each phase fails in its own way:

How to fix it#

1. Check the job's application settings#

Open Backup job › Guest Processing, confirm Enable application-aware processing, click Applications, select the Exchange VM and click Edit. On the General tab:

• Require successful processing fails the job on a VSS error. Try application processing, but ignore failures lets it finish with a crash-consistent backup, no truncation and only a warning that's easy to overlook.
• Select Process transaction logs with this job. Perform copy only never triggers truncation; use it only if another product owns Exchange backups.
• Don't exclude virtual disks holding databases or logs: Veeam's best-practice guide for Exchange shows truncation only when every database volume is in the backup.

2. Check guest credentials and connectivity#

Guest processing needs an account with local administrator rights on the Exchange VM and a network path from the backup server or a guest interaction proxy; use Test Now on the Guest Processing step. If a firewall forces Veeam into connectionless mode through VMware's VIX API, KB1680 says the account must be the built-in local or domain Administrator (SID ending in 500).

3. Reset the Exchange writer#

vssadmin list writers | Select-String -Pattern "Microsoft Exchange Writer" -Context 0,4
Restart-Service MSExchangeRepl
vssadmin list writers | Select-String -Pattern "Microsoft Exchange Writer" -Context 0,4

Outside the backup window, a Replication service restart normally brings back State: [1] Stable and Last error: No error; Veeam's KB1878 suggests a reboot if the writer is missing or stays failed. If the writer is missing on every DAG member, check the EnableVSSWriter value in KB2215. My Microsoft Exchange Writer guide covers every writer state and a Windows Server Backup control test.

4. Fix freeze timeouts#

KB1680 explains that Veeam Backup & Replication 8 and later switch to persistent VSS snapshots for Exchange automatically, which mitigates the 20-second limit unless one of Veeam's documented limitations prevents their use. When they can't be used, the snapshot has to fit the window again:

• Remove leftover snapshots from the Exchange VM before the job runs.
• Keep only one backup product's agent on the server.
• Check vCenter-to-host latency and datastore load in the backup window; add CPU or memory if the VM is starved.
• Confirm a plain Windows VSS backup of the VM works, proving the problem is snapshot timing rather than VSS itself.

5. Design DAG jobs the way Microsoft and Veeam expect#

• Back up passive copies, and never an active and a passive copy of the same database at the same time; Microsoft documents that the overlap fails with the Retryable error.
• Keep one DAG per job, with only the members needed to cover every database, ideally one holding only passive copies, as Veeam's guide recommends.
• Don't move databases while the job runs; watch for MSExchangeRepl event 2153 on the passive server, which points at the network path to the active server.
• If databases fail over during the backup window, check for cluster node removals (event 1135) and adjust cluster timeouts as Veeam's guide describes (KB1744).

Verify the fix#

The job should finish without VSS warnings; KB1878 shows the Veeam log line to look for, Notifying a VSS writer about the successfully backed up components. followed by Ok. Then, on the Exchange server:

Get-MailboxDatabase -Status | Format-List Name, LastFullBackup, SnapshotLastFullBackup
Get-MailboxDatabaseCopyStatus * | Format-Table Name, Status, CopyQueueLength, ReplayQueueLength -AutoSize

Good looks like LastFullBackup matching the job time, SnapshotLastFullBackup : True, healthy copies with near-zero queues, and a log folder that shrinks on every copy shortly afterwards. If logs still grow, follow transaction logs filling the disk.

Key takeaways#

• A green job isn't proof of truncation; LastFullBackup and the log count are.
• Copy-only, excluded disks and ignored failures all produce backups that never truncate logs.
• Back up passive copies, one DAG per job, never two copies of one database at once.
• For restores, see Veeam Explorer for Exchange restore errors.

References#

• VSS_E_WRITERERROR_RETRYABLE error when backing up a passive database copy (Microsoft Learn)
• Backup, restore, and disaster recovery in Exchange Server (Microsoft Learn)
• KB1680: VSS timeout when backing up Exchange VM (Veeam)
• KB1878: Exchange logs not being truncated (Veeam)