cancel
Showing results for 
Search instead for 
Did you mean: 

Exchange DAG - VSS Writer Missing

systemsadminist
Level 2

Here's some details about the environment:

  • Backup Exec 20.3 Rev. 1188 on a Windows 2016 Server.
  • Exchange 2013 DAG across 3 servers: Server A has half of our active databases (A-M) and half passive databases (N-Z). Server B has the other half of our active databases (N-Z) and half passive databases (A-M). There is a 3rd DAG server, Server C, which only has passive copies (A-Z). 

I'm experiencing an issue where the "Microsoft Exchange Writer" VSS writer goes missing after one or two successful Backup Exec jobs. Restarting the "Microsoft Exchange Replication" service brings the VSS writer back to "Vssadmin List Writers". That fixes the issue but it's getting frustrating having to do this every week, I need a permanent fix. 

The Backup job fails with the following: 

Final error: 0xe0008516 - The database specified for the snapshot was not backed up because the database was not mounted.
Final error category: System Errors

For additional information regarding this error refer to link V-79-57344-34070

I saw similar issues as mine online but they all seemed like older posts. I tried the Registry change that fixed the issue for many. I added the EnableVSSWriter with a value of 1 as instructed here: https://www.veritas.com/support/en_US/article.100028422 

I have the backup job set to "Back up from the preferred the server configuration only (Use the passive copy first and if not available, use the active copy...)" and our preferred server configuration is only Server A and Server B. We cannot backup from Server C since it is offsite. 

The backup method is "Full - Back up databases and logs (truncate log)". 

Advanced Open File is turned ON and set to use "Automatic - Allow VSS to select snapshot provider". Should this not be on? I saw a forum post from 2011 saying it shouldn't be on but I couldn't find anything in the Administrator's Guide to confirm this. Instant GRT is also enabled.

I haven't been able to find anything noteworthy in Event Viewer. 

Let me know if there's any other information I can provide that will help narrow this down. Any ideas what we can try?

 

5 REPLIES 5

CraigV
Moderator
Moderator
Partner    VIP    Accredited
Hi, If you're using the agent, uninstall it and then reinstall it. This might fix it. There was a lot of chat about turning AOFO off when backing up Exchange due to the manner in which the DBs were snapshotted. Turn it off, and then try the backup again. Make sure your logs are being cleared. Thanks!

Thank you but no luck. I completed all the steps you provided. 

The Microsoft Exchange Writer is still randomly disappearing from "Vssadmin list writers". I've searched Event Viewer during this time period also and nothing is standing out. 

criley
Moderator
Moderator
Employee Accredited

@systemsadminist 

If the Exchange writer is not showing when you run vssadmin list writers, I think it probably makes sense to contact Microsoft Support for help here. If you google this, there are lots of other people discussing the issue so I suspect this is not specific to Backup Exec.

If you are able to work with Microsoft on this, would appreciate it if you could keep us posted on progress.

See here:

https://serverfault.com/questions/739952/missing-exchange-writer-missing-system-writer-specific-serv...

Possible workaround is

sc config nsi type= own

followed by a reboot

So far, isolating the Network Storage Interface service in its own svchost instance as above is working for us.

Microsoft has fixed the issue in Windows 10 1703 and later by separating grouped services on hosts with more than 3.5GB of RAM:

https://docs.microsoft.com/en-us/windows/application-management/svchost-service-refactoring

"Benefits of this design change include:

  • Increased reliability by insulating critical network services from the failure of another non-network service in the host, and adding the ability to restore networking connectivity seamlessly when networking components crash.
  • Reduced support costs by eliminating the troubleshooting overhead associated with isolating misbehaving services in the shared host.
  • Increased security by providing additional inter-service isolation"

That seems like an admission of a fundamental design flaw in svchost shared services.