Veeam application-aware backup checklist

Symptoms to confirm

• 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.

Likely causes

With application-aware processing on, Veeam is the VSS requester inside the guest.

Checklist

1. 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. 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.

3. 3

   Reset the Exchange writer

   powershell

   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.

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