Solved

Windows backup on Server '12 HyperV parent returns error when backing up host component

Posted on 2014-09-15
7
876 Views
Last Modified: 2014-09-21
We have a Windows Server '12 HyperV parent that is running bare metal Windows Backups of itself and of its HyperV children.  The backups complete successfully except that they fail to backup the Host Component.  The exact error message is:
Error in backup of C:\\ProgramData\\Microsoft\ during enumerate: Error [0x8007007b] The filename, directory name, or volume label syntax is incorrect.
Application backup
Writer Id: {66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}
   Component: Host Component
   Caption     : Host Component
   Logical Path:
   Error           : 8078010D
   Error Message   : Enumeration of the files failed.
   Detailed Error  : 8007007B
   Detailed Error Message : (null)


Backups are being performed to a local USB drive.  All other components (bare metal, VHDs, etc) backup successfully.

Several months ago, I did a restore of a child's VHD to an "alternate location" so I could recover some files out of it.  If I recall correctly, something broke as a result.  I don't remember if the subsequent problem was that the VMs wouldn't restart properly or if they wouldn't back up.  I remember that some file location had been altered as a result of me backing up to an alternate location, and that I had to correct a registry entry to fix the problem.

I suspect that the current problem backing up the Host Component is somehow tied to whatever fix I had to do several months ago.  Unfortunately, I didn't document the problem or the solution, so I don't recall specifically what I did.  I do recall that whatever I did fixed the immediate problem.  Searching Google for assistance (even specifying experts-exchange.com) has proved fruitless.
0
Comment
Question by:SINC_dmack
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 4
  • 3
7 Comments
 
LVL 3

Accepted Solution

by:
Ken earned 500 total points
ID: 40324297
This may seem a silly question, but why do you have two backslashes before and after ProgramData in the path name? Is that the exact error? You may have entered this info incorrectly the first time around and that is why you had the failed backup previously.
0
 

Assisted Solution

by:SINC_dmack
SINC_dmack earned 0 total points
ID: 40324377
Ken, not a silly question--yes, that's the exact error message.  I fired up REGEDIT, and apparently the last time I opened it was when I made the change to fix whatever the problem was several months ago.  

The key is:
HKLM -> Software -> Microsoft -> Windows NT -> CurrentVersion -> Virtualization -> StoreLocation

The value is:
msxml://C:\\ProgramData\\Microsoft\\Windows\\Hyper-V\\InitialStore.xml

I think when I did the restore, that entry was changed to whatever folder I restored the VHD to.  I'm confident that the updated entry was made as a recommendation of whatever website I found the fix on.

I checked the same key on one of my other HyperV '12 Servers and its value is:
msxml://C:\ProgramData\Microsoft\Virtual Machine Manager\HyperVAuthStore.xml

All I can think is that the website where I found the fix had the wrong syntax, because there's no reason I would have consciously implemented extra slashes.  This is probably a case of me just taking at face value the purported fix and copy-and-pasting it into my affected server without questioning the syntax.  

So it seems pretty apparent that the server having the problem may have the wrong registry entry. I've copied the entry from the healthy server to the one experiencing the backup issues and will report tomorrow if this has fixed it.  Thanks!
0
 

Assisted Solution

by:SINC_dmack
SINC_dmack earned 0 total points
ID: 40324396
So, I rebooted the HyperV parent after changing the key to:
msxml://C:\ProgramData\Microsoft\Virtual Machine Manager\HyperVAuthStore.xml

The HyperV service wouldn't start.  Good thing I copied-and-pasted the original entry here.  I modified the key as follows and rebooted:
msxml://C:\ProgramData\Microsoft\Virtual Machine Manager\InitialStore.xml

The HyperV service wouldn't start again, so I reverted to the original key and rebooted:
msxml://C:\\ProgramData\\Microsoft\\Windows\\Hyper-V\\InitialStore.xml

The HyperV service started and all of the children became available.  

So, I went back and just took the extra slashes out of the key, after realizing that the healthy server had not only a different XML file, but that it was stored in a different location.  One more reboot, and everything came up properly, with the correct number of slashes in the registry key.  We'll see how the backup goes tonight.
0
2017 Webroot Threat Report

MSPs: Get the facts you need to protect your clients.
The 2017 Webroot Threat Report provides a uniquely insightful global view into the analysis and discoveries made by the Webroot® Threat Intelligence Platform to provide insights on key trends and risks as seen by our users.

 
LVL 3

Expert Comment

by:Ken
ID: 40325399
Sounds good. Yes, I try to backup any registry hives before making changes. I will check back to see how it went.
0
 

Author Comment

by:SINC_dmack
ID: 40325462
Last night's backup completed successfully.  

I Googled for "msxml://C:\\ProgramData\\Microsoft\\Windows\\Hyper-V\\InitialStore.xml" and found this site, which does include a fix with that exact syntax: http://zoomcloud.blogspot.com/2013/04/hyper-v-error-15500.html

I don't know if this was the specific site that I found several months ago when experiencing my initial problem after a restoring a VHD to an alternate location, but I feel at least a little better knowing that it's at least possible since there is at least one site with the fix with double slashes.  Thanks for your help, Ken!
0
 
LVL 3

Expert Comment

by:Ken
ID: 40326829
Glad you worked through it and thanks for posting your solution. Many times a simple comment makes you look at something a little different to find the right path. Might not even be the solution but gets you going. Take care.
0
 

Author Closing Comment

by:SINC_dmack
ID: 40335068
Ken's comment pointed me towards something that probably should have been apparent to me in the first place, and fortunately regedit on the affected server opened to the exact key that was causing the problem, making troubleshooting a lot simpler.
0

Featured Post

Free learning courses: Active Directory Deep Dive

Get a firm grasp on your IT environment when you learn Active Directory best practices with Veeam! Watch all, or choose any amount, of this three-part webinar series to improve your skills. From the basics to virtualization and backup, we got you covered.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Veeam Backup & Replication has added a new integration – Veeam Backup for Microsoft Office 365.  In this blog, we will discuss how you can benefit from Office 365 email backup with the Veeam’s new product and try to shed some light on the needs and …
Restoring deleted objects in Active Directory has been a standard feature in Active Directory for many years, yet some admins may not know what is available.
This tutorial will walk an individual through configuring a drive on a Windows Server 2008 to perform shadow copies in order to quickly recover deleted files and folders. Click on Start and then select Computer to view the available drives on the se…
Two types of users will appreciate AOMEI Backupper Pro: 1 - Those with PCIe drives (and haven't found cloning software that works on them). 2 - Those who want a fast clone of their boot drive (no re-boots needed) and it can clone your drive wh…

617 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question