VEX - undocumented functional limitation!!

[orangep7]

VEX (Veeam Explorer) Public Folder restores does NOT restore any customised folder permissions OR any mail-enabled folder config.

Unfortunately Veeam do not document this real-world limitation in their product and then bury their head in the sand if you query the behaviour.

Seriously unimpressed Veeam.

[Gostev]

Thanks for bringing this to our attention , James. I will ask our technical writing team to include this in the documentation. Please appreciate that it is quite hard to ensure all the things the product does NOT do are documented, as documentation is usually centered around what it CAN do. Thanks again!

[orangep7]

Can you repost this thread to the correct forum please so other VEX users are made aware please.

Regarding the "it's hard to ensure all the things the product does NOT do are documented" statement - I just don't agree with that logic because what we're talking about here is a fundamental shortfall in the product's ability to recover Exchange content.

Mail-enabled public folders are common place, as are customising pf folder permissions, and glossing over Veeam's inability to recover mail-enabled pf's and/or folder permissions simply makes a mockery of Veeam's "It just works" trademark!

[emachabert]

couldn't you use a virtual lab to recover those permissions ?

[Gostev]

Regarding the "it's hard to ensure all the things the product does NOT do are documented" statement - I just don't agree with that logic

I really am not sure what are you disagreeing with here, James. Nothing is flawless in this world. Documentation is written and validated by humans, and as such, it is prone to issues just like software itself. It is perfectly normal process when users report us bugs, inconsistencies, omissions in both software and documentation, and we then promptly fix those with product and documentation updates. Also note that in this particular case, you are actually the first to bring up this limitation here on these forums in 1.5 years of VEX existence, which is why it has not been documented (or addressed) before. Thank you!

[orangep7]

Yes I could have recovered the entire Exchange environment in a Lab (along with the AD dependencies etc) but that doesn't help me in a production environment when time is of the essence and I've been wrongly assuming that Veeam's "It just works" logo also relates to VEX.

This is not a bug it's a functional limitation in the VEX product, and not just a minor limitation either. This has every potential to bite users hard.

Veeam have actually been aware of this since at least October last year in v6.5 (I have the case number!) but for reasons I cannot understand have still chosen not to alert users to what is really quite an important limitation in VEX.

[Gostev]

Can you share the case number please?

While your support engineer was aware, it does not yet automatically makes anyone else at Veeam aware. I would like to understand what went wrong and why this was not escalated into R&D, to prevent these issues in future. Thing is, this would have certainly been fixed by now, if it was escalated back in 6.5 times

And I can assure you this certainly was not our "choice" not to document this limitation. There is really no good reason not to do this, as documenting saves us future support cases, and provides our users with more accurate description of B&R capabilities, ultimately leading to higher satisfaction.

[orangep7]

Previous case from September last year was # 00439689.

The reason I mention the "undocumented" issue is that we've hit it before in a few different situations, the worst example was a completely mangled Replica chain (see case # 00499907) which we eventually discovered was caused by the hot add feature not working correctly at the Target Veeam VM and we needed to apply more undocumented changes which Veeam Support were aware of (from memory it was to do with the hot add feature not working correctly at the target Veeam VM). In that situation after a month or two of continuous replication we suddenly and without warning lost the ability to use any of the replica chain and we were forced to bin everything and re-seed the replica VM from scratch!! We were just VERY lucky that the issue didn't coincide with an actual DR situation...

Please understand that we rely heavily on Veeam and problems like these leave us questioning what else hasn't been documented which could potentially affect stability.

Thanks