Veritas Backup Exec and Exchange Server: 0xE000FED1 writer errors, GRT and DAG backups

Backup Exec backs up Exchange through the Microsoft Exchange Writer, the VSS writer hosted by the Microsoft Exchange Replication service. When that writer is unhappy the job fails with 0xE000FED1; when the job or DAG settings are wrong you get skipped databases, untruncated logs or GRT restores with nothing to restore. Here's how to find the guilty side on Exchange Server SE and Exchange 2019, fix it and prove it.

Symptoms#

Admins report job logs like these when the job fails (server and database names will differ):

Final error: 0xe000fed1 - A failure occurred querying the Writer status. See the job log for details about the error.
V-79-57344-65233 - Snapshot Technology: Initialization failure on: "\\EX02.contoso.com\Microsoft Information Store\DB01". Snapshot technology used: Microsoft Volume Shadow Copy Service (VSS).
Snapshot technology error (0xE000FED1): A failure occurred querying the Writer status. See the job log for details about the error. Check the Windows Event Viewer for details.
Writer Name: Exchange Server, Writer ID: {76FE1AC4-15F7-4BCD-987E-8E1ACB462FB7}, Last error: The VSS Writer failed, but the operation can be retried (0x800423f3), State: Failed during freeze operation (9).

Another reported variant ends with Last error: The VSS Writer timed out (0x800423f2). On the Exchange server, vssadmin list writers shows the Microsoft Exchange Writer with Last error: Retryable error (or Non-retryable error or Timed out), or stuck in [5] Waiting for completion. Related signs:

• BackupInProgress stays True long after the job ended.
• The job "succeeds" but logs keep growing and LastFullBackup doesn't move.
• A passive-copy-only DAG job fails because no passive copy is available.
• GRT jobs crawl, or individual items aren't offered at restore time.

Why it happens#

Backup Exec asks VSS for a snapshot and the Exchange writer decides whether the database can be backed up; 0xE000FED1 means the writer answered with an error. The cause is usually on the Exchange server, in the job definition, or in another product holding the writer.

How to fix it#

1. Check the writer where the snapshot ran#

In a DAG the snapshot runs on whichever member hosts the copy Backup Exec picked, so run this on every member (or at least on the one named in the job log):

vssadmin list writers
Get-MailboxDatabase -Status | Format-Table Name, Server, BackupInProgress, LastFullBackup, LastIncrementalBackup -AutoSize
Get-MailboxDatabase | Get-MailboxDatabaseCopyStatus | Format-Table Name, Status, CopyQueueLength, ReplayQueueLength -AutoSize

Good looks like State: [1] Stable and Last error: No error for the Microsoft Exchange Writer, BackupInProgress False, and copies that are Healthy with queues close to zero.

2. Reset a stuck writer#

Restarting the Microsoft Exchange Replication service resets the writer. Do it in a quiet period, and if the node hosts active copies, move them first or use maintenance mode:

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

If the writer fails again on the next run, find what else snapshots the server in the same window — only one application-aware backup should touch an Exchange server at a time. If it won't return to Stable even after a restart, reboot the node in maintenance mode and work through the product-neutral checks in Microsoft Exchange Writer failed or retryable.

3. Remove the causes of timeouts#

• Backup Exec's best practices: don't run Information Store maintenance during the database backup, and run Exchange jobs separately from other backup jobs.
• vssadmin list providers and vssadmin list shadowstorage reveal third-party hardware providers and volumes short of shadow-copy space.
• Back up a copy in the Backup Exec server's site, not across a WAN link.

4. Configure the DAG job the way Backup Exec expects#

• Install the Agent for Windows on every DAG member and enter an Exchange Agent licence for each one.
• Select databases through the DAG container (the entry with the Exchange logo) on the Backup and Restore tab; edit the job when you add databases.
• In Backup Options › Microsoft Exchange, choose Back up from the passive copy and if not available, try the active copy (recommended) with a preferred server configuration. Back up from the passive copy only requires preferred servers and fails when no passive copy is available.
• Repair failed or suspended copies first (FailedAndSuspended and reseeding).

5. Use a method that truncates logs#

Full - Back up databases and logs (truncate logs) and Incremental - Back up logs (truncate logs) remove committed logs; Full Copy and Differential leave them in place. Incremental and differential jobs also need circular logging disabled. In a DAG, each copy truncates only after the logs are replicated, and lagged copies keep theirs — if space is already tight, see transaction logs filling the disk.

6. Meet the GRT requirements#

• Enable Use Backup Exec Granular Recovery Technology (GRT) to enable the restore of individual mailboxes, mail messages, and public folders from Information Store backups in the Microsoft Exchange options.
• The service account needs local admin rights on the Exchange servers plus full Exchange permissions or the minimal set Backup Exec documents for GRT.
• Move the GRT staging location off the system volume and keep GRT backups under about 75,000 log files (Backup Exec best practices).
• Send fulls, not GRT incrementals, to deduplication storage; incrementals belong on a disk storage device.

7. When a restore fails#

Restoring over an existing database needs Set-MailboxDatabase DB01 -AllowFileRestore $true, and in a DAG the passive copies must be reseeded afterwards. For single mailboxes, restore into a recovery database and copy data back with New-MailboxRestoreRequest. If a restored database won't mount, see database won't mount.

Verify the fix#

• The Microsoft Exchange Writer is Stable with No error on every member before and after the job.
• The job completes without exceptions, LastFullBackup matches the job time and BackupInProgress is False.
• Log counts drop on every copy after the full backup.
• A test GRT restore of one message to a test mailbox works.

Prevent it next time#

• Alert on the age of LastFullBackup, not only on the job status.
• Give each Exchange server one application-aware backup, away from maintenance and migration batches.
• After every Exchange CU or a move to Exchange Server SE, check the Backup Exec Software Compatibility List and update the agents.
• Add new DAG members and databases to the job the day you create them.

Related: NetBackup and Commvault with DAGs and the VSS and backup error codes quick reference.

References#

• Backing up Exchange data (Backup Exec 25.1 Administrator's Guide)
• Requirements for using the Exchange Agent (Backup Exec 24 Administrator's Guide)
• Monitor database availability groups (Microsoft Learn)