XGE VSS Backup / MS Compliance

[Bunce]

Hey Guys,

My understanding was that Veeam was fully compliant as per MS requirements for VSS backups.

A post was made in the ARS forums indicating that Veeam wasn't supported by MS which I disagreed with. A Microsoft Employee then referred to this blog post to reinforce his belief that Veeam isn't compliant - specifically the 'proprietary VSS implementation' statement.

The MS rep is IMO an excellent resource and very knowledgeable in regard to XGE so thought you might like to weigh in on this, or at least verify the wording in the blog post, as MS may well use it as a reference to not provide support based on their interpretation of proprietary VSS.

Cheers,
A

[tsightler]

Veeam does utilize the "Exchange VSS writer" exactly as required. The page specifically states "proprietary VSS integration" as in, we don't require a persistent agent to call VSS but actually push a small VSS runtime agent. In the end, this agent simply calls the underlying VSS writers and asks them to do the "right thing". We don't have our own VSS writer. The proprietary part is simply the code that actually intergrates with the native VSS API, i.e. how we actually coordinate that with VMware snapshots and how we purge logs only after successful backup, etc.

[Bunce]

Yup thats basically what I've posted Tom.

I reckon it might pay to tweak the wording in that blog as reading it as an outsider (as the MS Rep was) can suggest its not using the XGE VSS writer, but a custom Veeam VSS implementation instead.

This has since been suggested by the MS Rep in the above post.

[Gostev]

Tom is spot on, we never even say "Proprietary VSS implementation" in this post, so I am not sure this Microsoft guys is talking about. "Proprietary VSS integration" means that we do not rely on "native" VMware Tools VSS integration, like other VMware backup products do. The reason being is that VMware Tools VSS does not meet Microsoft requirements of Microsoft Exchange backup (plus, we had our VSS integration even before VMware had added theirs).

P.S. I just read the topic now and Andrew, you are also spot on for what "proprietary integration" stands for.

[Bunce]

we never even say "Proprietary VSS implementation" in this post, so I am not sure this Microsoft guys is talking about. .

The blog sets our the three 'rules' for compliancy. The first rule:

Rule 1: Exchange must be backed up exclusively through the Exchange VSS Writer.

The very first line of the response:

Rule 1: VSS Aware Backup
Veeam implements proprietary VSS integration since 2.0

Which can quite easily be read as 'Veeam doesn't use Exchange VSS writer but its own implementation'.

The Microsoft rep is 100% spot on - wasn't having a go at Veeam - and gave valid advice.

I realise you're due for a break Anton and its been a long year, but perhaps ease off on this defensive attitude a little - especially when someone is trying to help your product.

[Gostev]

I realise you're due for a break Anton and its been a long year, but perhaps ease off on this defensive attitude a little - especially when someone is trying to help your product.

I certainly much appreciate your help, but why making me look like some sore and tired dude counting days to vacation? As a matter of fact, I still do emails and forum even on my "breaks" (just don't go to the office), so all my holidays have been pretty "virtual" past 5 years. I cannot afford to go offline and long forgot what the "real" vacation is...

I am not defensive at all, I am just stating the fact. Fact: we never say "Proprietary VSS implementation" anywhere in the blog post, as claimed in the original post here. Indeed, this phrase does not make any sense whatsoever, and it would confuse myself as well. Do you agree that the quote in your first post does not actually exist in the blog post? That was my only point. Nothing more, nothing less, nothing about being defensive.

"Proprietary VSS integration", on the other hand, is the technically correct statement - our integration with Microsoft VSS framework is proprietary, as it does not rely on VMware Tools VSS provider. Every backup software must integrate with, and leverage Microsoft VSS framework correctly to meet Microsoft requirements. What can possibly be wrong with stating that the backup product "integrates" with Microsoft VSS? Isn't this exactly what every backup product out there is supposed to do?

I think this Microsoft guy only got confused because he did not read carefully. The Rule 1 of Microsoft Exchange backup is introduced in the blog post as "Exchange must be backed up exclusively through the Exchange VSS Writer", ans then we explain how we meet the requirements of Rule 1 in more details. Yet, he insists we are not using one "Veeam ... does not utilize the Exchange VSS writer"? Huh? Does not make any sense.

What would be your suggestions on re-wording?

[Bunce]

I am not defensive at all, I am just stating the fact. Fact: we never say "Proprietary VSS implementation" anywhere in the blog post, as claimed in the original post here. Indeed, this phrase does not make any sense whatsoever, and it would confuse myself as well. Do you agree that the quote in your first post does not actually exist in the blog post?

The easiest way to clear it up is to clearly indicate that Veeam triggers the Exchange VSS writer - which is a direct response to the 'rule 1' listed. Currently a user looks at the response to rule 1 and the first thing they read is a line to suggest a proprietary Veeam VSS method, followed by 'Supported by Veeam' (suggesting not Microsoft) and nothing about the Exchange Writer.. which is exactly as a Microsoft rep did who came across the article, who will be the people answering support calls and possibly referring to the first google response on whether Veeam correctly implements XGE backups - and telling Veeam customers they won't help because its not supported.

If you don't think that is misleading then fine - you're free to do what you want with it.

[Gostev]

I have added references to VMware Tools VSS to make it more clear.