Veeam Endpoin & Win10 1709

[NugentS]

This morning Windows 10 - Veeam enpoint working just fine
Install 1709
Run Backup
Now I get the error: 26/10/2017 22:44:04 :: Calculating digests Error: Cannot find shadow copy of volume \\?\Volume{2bb7e26b-fc33-4bab-90f3-6c87243d80e9}

Any ideas?

[Dima P.]

Hello and welcome to the community Sean,

May I ask you to submit a support case via Control Panel > Support > Technical Support (it's free) and share the case ID with me.

[NugentS]

Sorry - this may sound dumb - but I cannot.

I get to the correct page - but there are two questions.
1. Type - not a real issue
2. Product - the product isn't there

I have royally naffed things up anyhow now by trying to remove the product - which won't remove - so not sure what to do now

[NugentS]

OK - it was me being dumb

Support case opened: 02361505

Sorry

[ta_jb]

Same for me... Do you need an additional support case?

[NugentS]

I finally managed to remove all the binaries etc - not the database and reinstall. (needed brute force and ignorance)

Same issue - but pointing to a different folder

Sean

[Felyrion]

I have the same error since updating to Windows 10 build 1709:

27-10-2017 15:13:55 :: Calculating digests Error: Cannot find shadow copy of volume \\?\Volume{bfe22e32-e573-4e71-b8d9-4a8be8c4a824}

I just opened a support case, number 02362322


edit:
Strange, I tried different things, including the trick to re-add disks to the database by changing to file backup and re-run the backup. Nothing helped.
But ofcourse, as soon as I made a support case, the backup started running by schedule, and to my surprise it started working again!

I guess something I did helped in the end, but sorry... I have no idea what

[SKratzTS]

"Me too" but it's giving me a PermisionDenied error when it tries to upload logs.

[Dima P.]

Hi all,

QA team is investigating this issue. Confirmed resolution is to recreated database. Please keep in mind that this workaround will erase your job configuration and you have to reconfigure the backup job again. All backup files remain untouched and it should be possible to continue backup chain if you point your backup job to the same destination.

[SKratzTS]

FYI - VSSADMIN LIST WRITERS -- shows SQL Agent VSS "Retryable error"

[Dima P.]

Steve,

Please PM me your contact email address, I'll ask to open a support case for you.

[Dima P.]

But ofcourse, as soon as I made a support case, the backup started running by schedule, and to my surprise it started working again!

Any chance additional reboot was performed before next backup job run?

[SKratzTS]

Well poo -- I already ran the Windows Cleanup to get rid of the old windows.old folder referenced in the KB article. I'll try recreating the DB & see if it works...

[SKratzTS]

...Job is starting now, but it's creating a brand new backup chain. "Backup Job Computer" was the old folder, "Backup Job Computer_1" is now being written to.

Oh well, not mission critical, but 8TB of data to spool off to the backup drive.

[Dima P.]

Thanks! Asked support team to create a case for you.

[NugentS]

Some more info from me.
After uninstall, reinstall, recreate database etc
The backup works - the first time. HOwever if I try to repeat the backup I get VSS errors and the backup fails
If I reboot, then the backup works, again once

This is repeatable

Sean

[ben.nakagawa]

I had similar issue and end up disabling bitlocker.

post258126.html?hilit=1709#p258126

[willrun4fun]

I have the same issue. Several of them are on fresh installs from scratch so it's not an upgrade but a compatibility error.

[yasuda]

Does this apply to both Veeam Endpoint Backup 1.5.0.306 and Veeam Agent for Windows 2.0.0.700?

[Dima P.]

Hi folks,

We are still investigating this issue. Meanwhile you can use a recreate database workaround I proposed earlier in this thread.

P.S. Please do not forget to submit support cases and share them in this thread. Thank you.

[Dima P.]

Hello,

Sharing the last-minute update from QA team about this issue.

Root cause: During upgrade to Windows 1709 EFI system partition was modified. If it's included in the backup scope (i.e. volume level backup > OS volume and system partitions or file level backup > operating system check box) then it should be processed by backup job. Since the partition was modified Veeam Agent for Windows is unable to create a VSS snapshot and, as a result, backup job fails.

Solution 1: Recreate database per this article. Drawback – your backup chain will be started from a new full backup and the old backup chain won’t be affected by retention.

Solution 2: Switch existing backup mode to Entire PC and save backup job configuration (there is no need to start backup job). It’s recommended to take a screenshot of your settings before you change the backup mode. Open backup wizard again and revert settings back to the desired ones and save the job. Backup job should continue the existing chain.

Solution 3: Reach our support team via Control Panel > Support > Technical Support and they will share a hot fix for this issue.

P.S. The mentioned fix is going to be included in the upcoming update for Veeam Agent for Windows.

[ben.nakagawa]

In my case recreate database workaround did not fix and find out the problem was caused by recovery partition having no shadow storage allocated and not enough space left for that (56MB free space was in there).

I have updated my findings on other thread here post258126.html?hilit=1709#p258126

[colshaw]

We also have this issue but only with our UEFI systems as the Legacy\MBR system run ok on Windows 10 1709. (Entire PC Backup)

BitLocker enabled.

Database recreate - still failed.

Hotfix provided by support applied - still failed.

Case # 02385876

[mdowney]

Any chance you have Webroot on that computer? I ran into a similar issue. They have a known issue which they've just release a fix for. If you have Webroot, check here:

https://community.webroot.com/t5/Produc ... d-p/305469

[colshaw]

No we do not use any Webroot solutions.

Support updated us as follows:

Thank you for confirming that. Prior build 1709 it was possible to store shadow copies of FAT32 volumes on Bitlocker-enabled NTFS volumes (EFI partition is FAT32). After build 1709 it is not possible. It means that if you don't have other NTFS volumes (without Bitlocker), it is not possible to store a shadow copy of EFI partition.

Note that usually Microsoft creates 3 partitions on UEFI systems: EFI partition, Recovery partition and system partition (C:\ drive). Recovery partition is NTFS, therefore it can store shadow copies for EFI partition.

Workaround for this issue is creating a new NTFS volume without Bitlocker to store shadow copies for EFI partition. Also you can try disabling BitLocker.

[packergeek]

I had the same issue with two clients who were using it. I'm sure I will be contacted by other clients who use it as well. Do we have any eta for the update?

[Dima P.]

Hi folks,

If the solution mentioned in this thread is not working for you please open a support case and share the case. Support team will review your logs and share the investigation with us. Thank you in advance.

[Anguel]

My solution was the following:
Kind of "recreate" the backup job by simply going through the Configure Backup wizard (next, next, next and save the job) then rerun the job.
I did not change anything else, e.g. no database, no reinstall.
Will watch if the problem reappears on other computers. On another laptop I only got a warning that the disk layout had changed...

Hope this helps,
Anguel

[Anguel]

UPDATE: The problem showed up on another PC right after the 1709 upgrade. But just stepping through the wizard may not be enough. In the Wizard under Volumes check the "Show system and hidden volumes" checkmark - for some reason C: was checked but the special volumes were NOT! So make sure that you uncheck C: and then check it again to make sure that the special volumes are also selected. Then next, next, next and apply. This solved the problem. Maybe I did this on the previous PC too but did not notice, I will see on other PCs...

[Anguel]

UPDATE 2: It seems that the problem occurs on all of my Dell Optiplex desktops after 1709 upgrade and I can confirm that deselecting and reselecting the C: volume in the backup settings solves it immediately.
I am using Kaspersky Endpoint Security if that is of any importance.