Vss writers failed state 9,Exchange logs are not purged.

[d.lansinklesscher]

I just started backing up an Exchange 2007 server for a customer of hours. Application aware processing and truncation of logs is enabled. The job completes fine and everything is green in Veeam. But when I log on to the machine the logs are not truncated and various VSS-writers are in this state:

Code: Select all

Writer name: 'COM+ REGDB Writer'
   Writer Id: {542da469-d3e1-473c-9f4f-7847f01fc64f}
   Writer Instance Id: {cdd86dc8-b14c-404c-93ef-c8937ce792e0}
   State: [9] Failed
   Last error: No error

Writer name: 'Microsoft Exchange Writer'
   Writer Id: {76fe1ac4-15f7-4bcd-987e-8e1acb462fb7}
   Writer Instance Id: {3350399e-8b65-4471-9cf5-19d9275f04f5}
   State: [9] Failed
   Last error: No error

Writer name: 'BITS Writer'
   Writer Id: {4969d978-be47-48b0-b100-f328f07ac1e0}
   Writer Instance Id: {57c1cdd7-75ed-4180-86cb-ca6bd1df8826}
   State: [1] Stable
   Last error: No error

The VM os is Server 2008 R1

Question one: Has anyone ever expierenced this issue?
Question two: Why doesn't Veeam give a warning about the logs not being truncated?

[foggy]

Dennis, what Veeam B&R version are you at and what is your support case ID? Thanks.

[d.lansinklesscher]

Alexander, version is 8.0.0.2029. Haven't created a case yet. I'll create one right now.

[foggy]

Any related messages in Event Viewer on the affected VM?

[d.lansinklesscher]

Just got a reply from support, they came up with this article which completely fits our situation:

https://support.microsoft.com/en-us/kb/2952783/en-us

It explains that errors are expected and can be ignored. It does however not explain why the logs are not truncated.

[foggy]

Please continue working with your engineer on that.

[d.lansinklesscher]

I notified the engineer our customer is running Exchange 2007 SP1 and that I found this article that says volume based back-up of Exchange 2007 is introduced in SP3:
https://technet.microsoft.com/en-us/lib ... g.80).aspx

To which he replied:

We support every OS Microsoft supports:

All operating systems supported by Microsoft Hyper-V.
You can check everything here: http://h ... pport.html
Unfortunately cannot guarantee that log truncation would work in this scenario, I believe it's better to consult with Microsoft support here.

I let him know I'll have my client update Exchange to SP3. And asked him if Veeam isn't responsible for the log truncation.

To be continued.

[d.lansinklesscher]

It turned out I looked in the wrong place and our client was already running SP3. The final answer I got from support is that it's a Microsoft issue and there's nothing to do about it.

I can understand that it's a Microsoft issue and that it's not something Veeam can fix. But apparently everybody that runs Exchange 2007 on server 2008 on Hyper-v 2012R2 will have this problem. Therefor I think that maybe it's worth mentioning in something like "Exchange 2007 detected, logs will not be truncated"

Because of course I need my logs to be truncated I created a workaround: A postthawnscript that creates another volume shadow and releases it. Because this shadow copy does not get aborted it causes the logs to be truncated.
I run Diskshadow -s C:\scripts\diskshadow.txt

Diskshadow.txt contains:
Add volume c:
Add volume d:
Add volume g:
Add volume H:
Begin backup
create
End backup

It's not really pretty but it works.

[foggy]

Dennis, could you please share your case ID, so I could get more information regarding the actual Microsoft issue they are talking about?

[d.lansinklesscher]

Alexander, Case # is 00948060

[foggy]

Could you please point me to the description of the Microsoft issue as I cannot get anything about that from the case. Thanks!

[d.lansinklesscher]

Just got a reply from support, they came up with this article which completely fits our situation:

https://support.microsoft.com/en-us/kb/2952783/en-us

It explains that errors are expected and can be ignored. It does however not explain why the logs are not truncated.

[foggy]

Dennis, I've passed this to QA for internal confirmation. In case of success, we'll consider the ability to warn user in such cases. Thanks.

[ChrisJ83]

I think the issue is with Windows 2008, we have the same issue and are in the process of moving to Windows 2008 R2 for the Exchange installation and hopefully this will resolve the issue as it did in our test environment.

cheers