VSA failed to Collect File Details while Windows Recovery Partition Typ 27 ist present

@JoergR , I spoke to a few colleagues to see if I could get an answer for you and they all suggested opening a case directly with support.

Can you get a case created and share the incident number here?

Hello Mike, i have opened a Ticket, but we have 1st Level Support from Fujitsu. I will provide he incident number as soon as possible.

Thanks, @JoergR !  If possible, ask for the CV ticket number.  I can possibly track the FJ number, but not always.

Hello Mike, i have asked for the CV ticket number but for the moment i have ony the Fujitsu one (W668012549). I give you an update if i have any news. 

Hello Mike, CV Ticketnummer is 220429-197. Best regards, Jörg

Perfect, thanks!  I’ll follow for resolution.

The Problem is not such easy as it seams. It is a combination of a Windows System with BIOS and MBR DISK Partitioning and present Windows Recovery Disk (with ID 27) and VTL as Backup Target.

Commvault can't read the Disk ID 27 and because partial metadata collection of Volumes is not supported for VMs, it tried to do Live Browse Operation what doesn’t work because Live Browse isn't supported for (Virtual) Tape Librarys.

For the moment we are testing a key that should enable that.

This is just a guess but…
Could this be a problem with the type of media agent you are using?

for Linux media agents browsing NTFS data doesn’t use native NTFS, in fact at one point it wasn’t even possible to browse NTFS volumes due to the inability of Linux to read NTFS at the time. 

The only reason I mention this is because I have never personally experienced this issue. 
The way I thought live browse worked was that it reconstituted the extents on the fly, so it should not matter what target it’s browsing from. NTFS Linux incompatibilities would make more sense.

as a test you could use a windows media agent as a proxy for the browse, as you can imagine this test may not be definitive as I assume the windows MA would would then reconstitute the extents locally but that is just a guess.

Hi Christopher, we use an Windows Media Agent. This is an issue with a Windows MediaAgent and a Windows Client. If there is no ID 27 browsing worked fine. For Linux browsing we use FREL.

We found differnt ways to workarround the problem.

1. You can change the partition typ for the recovery partition. No Partition ID 27, no problem to browse, because partial browse of volumes is not nessecery. 
2. You can delete the recovery partition. No Partition ID 27, no problem to browse, because partial browse of volumes is not nessecery. 
3. You can change BIOS/MBR to UEFI/GPT. No Problem because GPT Recovery Partition has ID="de94bba4-06d1-4d40-a16a-bfd50179d6ac".
4. You can set a Key that enables partial browse of volumes, what we are testing now.
   For me the fastest and cleanest way to change.

That seems like a lot of work. Dangerous work at that.

if the issue is caused by the target your are restoring from would a spool copy help at all?

then during a restore choose the first copy to restore from.

Definitely an interesting issue.