upgrade to v9 and Exchange 2013 DAG backup warning

[Markus.K1985]

We have the same issue at the moment and also opened a Case.

Any result so far?

[pshute]

We have had this problem for weeks now. Is there a definitive fix we can do?

[foggy]

I've checked the last case mentioned above and it was closed due to no response from the customer. Please contact support directly, they will be able to verify your issue and advise in case there's a solution available.

[pshute]

Thanks, we got a good backup without the error last night, so I'm hoping we've fixed it permanently. I ran "vssadmin list writers" on the mail server after posting that, as suggested above, and could see Microsoft Exchange Writer reporting a failed state. We removed a couple of databases we had previously dismounted because of errors, and then restarted services as suggested above (veeam-backup-replication-f2/upgrade-to- ... ml#p181174), and then Microsoft Exchange Writer was no longer reporting a failed state. Then the evening backup was ok.

I'm not sure which of those actions fixed it. It might be that I forgot to restart the services after dismounting the databases, and that removing the databases wasn't necessary.

[jwz88]

Hi,

We also have this issue since the start of v9.
I have tried everything, also opened a support case which has been closed a long time ago as I gave up.

But its really bothering me a lot, especially since other people are having the same problem.

Exchange 2013 CU11 DAG, but the issue also persisted at CU7.
Sometimes the backup runs OK without warning, but that's like 5% of the time. The rest it gives this warning:

30-8-2016 01:52:31 :: 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: [{8f4c280e-5be6-455d-be15-176709528c84}]. Writer's state: [VSS_WS_FAILED_AT_BACKUP_COMPLETE]. Error code: [0x800423f3].

Its on the same patch levels as our other DAG members, which do not display any errors.
All members are running Active and Passive databases.
I have reseeded all the passive databases already, but also no success.

At this point I have no clue what to do anymore...
When running a manual shadow copy all seems fine....

[Andreas Neufert]

Thanks for the feedback. I updated myblog post with tips and tricks.
http://andyandthevms.com/exchange-dag-v ... plication/

At jwz88 can you please check the tips in this thread and on my blog post.
At least did you increased Failover CLuster heartbeat to max values and mount or delete unmounted databases?

[jwz88]

Hi Andreas,

Yes, I have changed the heartbeat to the recommended settings in the Veeam KB article.
We don't have a failover occurring at backup time, we never had but changed this setting anyway when I contacted support a while ago.

We do have some dismounted databases, but those are passive databases from other servers. The other servers are running the exact same config but experience no issues.

At backup time, the CPU load at backup time is approx. 7 %, about the same as the other exchange servers.
Backup is being run on NBD mode, latencies about 2 ms.

The exchange logs are being truncated though. I even enabled circular logging for a weekend to disable it afterwards, this did not change anything either.

The weird thing is, sometimes the backup does go OK (very, very rarely) without any changes.
If anyone has any pointers that'd be great...

[rogerdu]

I get this error now as well... Exchange Replication jobs failing, but here's the twist... NetApp integration is failing and I cannot create a storage snapshot. case 01989645 opened with Support as it is showing as a VSS error (with the same error code 800423f3) because it gets a VSS timeout when using the "regular" snapshot mechanism... GRRR all was working for a whole 2 days!!

[rogerdu]

Ignore the troll in the corner... it seems my client was running a backup at the same time I was... while his VSS session was in use, I could not create a new one... once his job finished, everything I had put in place fell back to the blissful green state we all like to see. Case closed...

[Andreas Neufert]

Good to hear and thanks for the update. Be careful with the log truncation. If the customer uses the other software on a regular base and this software uses Logfile processing you can place our job to "Copy only".

... and hey, we learned a new root cause for this error message.

[rogerdu]

for the replication jobs, I am already using the copy only functionality. The daily backups does the truncate logs function.

[CraigF142]

Same issue:

VSS: Backup job failed. Cannot notify writers about the 'BACKUP FINISH' event. A VSS critical writer has failed. Writer name: [SqlServerWriter]. Class ID: [{a65…}]. Instance ID: [{fff…}]. Writer's state: [VSS_WS_FAILED_AT_BACKUP_COMPLETE]. Error code: [0x800423f4

Fixed by:

1. powershell: vssadmin list writers

1. Note which vss writer is failed (in this case was SQLServerWriter)

1. Look up service in services control panel and restart service (originally showed in control panel as running)

1. Rerun powershell to verify no errors

[Andreas Neufert]

Thanks for sharing...
please keep in mind that some of the services register their VSS writer only after some time. So for example when you restart the service and immediately perform a backup, the service maybe didn´t added the VSS writer and you have no consistency for this application.
You can double check with vssadmin list writers if it back in the VSS writer list.

[captaincrunch00]

I know this is a very old post, but I had the same error. I had an unused mailbox database dismounted on my exchange 2016 server. If I mount the database it will run and not kick back the error. After deleting the database the error does not show up.

So maybe people reading this can check that too. I was on 9.0u2, and now got the same error on 9.5u4.

I registered to post this because this thread is the first that shows up when googling the error. Hope it helps someone.

[foggy]

Thanks for taking the time to register and sharing your findings, much appreciated!