Windows Server TechCenter > Windows Server Forums > Hyper-V > Restored VMs and .VHDs and Lost Security Settings

Answered Restored VMs and .VHDs and Lost Security Settings

  • Saturday, April 25, 2009 7:48 AM
     
     

    I had to restore the virtual machines and the virtual drives from a backup.  Unfortunately, the backup did not have the individual security settings for each VM and VHD.

    I cannot start any of the VMs.  The error message is:
    [Window Title]
    Virtual Machine Connection

    [Main Instruction]
    The application encountered an error while attempting to change the state of 'VM Windows XP SP3 - VS2008'.

    [Content]
    'Unnamed VM' failed to initialize.

    An attempt to read or update the virtual machine configuration failed because access was denied.

    [Expanded Information]
    'Unnamed VM' failed to initialize. (Virtual machine 54DB75B6-3BA0-424F-B48C-7FFECC7CE669)

    'Unnamed VM' failed to read or update the virtual machine configuration because access was denied: General access denied error (0x80070005). Check the security settings on the folder in which the virtual machine is stored. (Virtual machine 54DB75B6-3BA0-424F-B48C-7FFECC7CE669)

    [^] Hide details  [Close]

    Each of the pieces of a newly defined VM -- the xml file, the empty directory and the virtual hard drive -- have full control for an object that has the same name as the guid for the virtual machine.  So for the example above there should be a security setting for an object named 54DB75B6-3BA0-424F-B48C-7FFECC7CE669 with full control.  Unfortunately there isn't and there does not appear to be a way to add it as it is not in the list of objects that can be assigned.

    Is there a way to repair the security settings?

Answers

  • Monday, April 27, 2009 2:47 AM
    Moderator
     
     Answered

    Hi,

     

    You can use the icacls command to grant the permission:

     

    Grant full access to the virtual machine’s security identity using the command:

     

    icacls "%SYSTEMDRIVE%\ProgramData\Microsoft\Windows\Hyper-V\Virtual Machines\befde5dd-dc82-4575-9ca7-57625301ccb9.xml" /grant "NT VIRTUAL MACHINE\befde5dd-dc82-4575-9ca7-57625301ccb9":F /l, then you should be able to run the VM properly.

     

    Note: Please replace the “befde5dd-dc82-4575-9ca7-57625301ccb9” with the GUID of the specific VM you want to grant.

     

     

    Best regards,

    Vincent Hu

     

     

  • Thursday, April 30, 2009 2:18 AM
     
     Answered

    The first time I tried it the command failed because I had deleteted the VM to be able testing the restore of a VM to a system that did not have it defined.  For example if the OS was restored from a point before the VM was defined.

    From: http://social.technet.microsoft.com/Forums/en-US/winserverhyperv/thread/3b0db540-cceb-4dd9-9b8a-3de6840bc03b

    I found information on the need to recreate the symbolic link first.

    So I ran:
    X:\>mklink "C:\ProgramData\Microsoft\Windows\Hyper-V\Virtual Machines\1AF87BDE-F
    775-4977-8557-275F7909166C.xml" "V:\VirtualMachines\Virtual Machines\1AF87BDE-F7
    75-4977-8557-275F7909166C.xml"
    symbolic link created for C:\ProgramData\Microsoft\Windows\Hyper-V\Virtual Machi
    nes\1AF87BDE-F775-4977-8557-275F7909166C.xml <<===>> V:\VirtualMachines\Virtual
    Machines\1AF87BDE-F775-4977-8557-275F7909166C.xml

    Then:

    X:\>icacls "C:\ProgramData\Microsoft\Windows\Hyper-V\Virtual Machines\1AF87BDE-F
    775-4977-8557-275F7909166C.xml" /grant "NT VIRTUAL MACHINE\1AF87BDE-F775-4977-85
    57-275F7909166C":F /l
    processed file: C:\ProgramData\Microsoft\Windows\Hyper-V\Virtual Machines\1AF87B
    DE-F775-4977-8557-275F7909166C.xml
    Successfully processed 1 files; Failed processing 0 files

    I could connect to the VM but I could not start it:

    [Window Title]
    Virtual Machine Connection
    [Main Instruction]
    The application encountered an error while attempting to change the state of 'Test Security Settings'.
    [Content]
    'Unnamed VM' failed to initialize.
    An attempt to read or update the virtual machine configuration failed because access was denied.
    [Expanded Information]
    'Unnamed VM' failed to initialize. (Virtual machine 1AF87BDE-F775-4977-8557-275F7909166C)
    'Unnamed VM' failed to read or update the virtual machine configuration because access was denied: General access denied error (0x80070005). Check the security settings on the folder in which the virtual machine is stored. (Virtual machine 1AF87BDE-F775-4977-8557-275F7909166C)
    [^] Hide details  [Close]

    The security settings for the XML file, the VHD file and the empty directory were not updated to include the 1AF87BDE-F775-4977-8557-275F7909166C account.

    I then ran:

    X:\>icacls "V:\VirtualMachines\Virtual Machines\1AF87BDE-F775-4977-8557-275F7909
    166C.xml" /grant "NT VIRTUAL MACHINE\1AF87BDE-F775-4977-8557-275F7909166C":F /l
    processed file: V:\VirtualMachines\Virtual Machines\1AF87BDE-F775-4977-8557-275F
    7909166C.xml
    Successfully processed 1 files; Failed processing 0 files
    X:\>icacls "V:\VirtualMachines\Virtual Machines\1AF87BDE-F775-4977-8557-275F7909
    166C" /grant "NT VIRTUAL MACHINE\1AF87BDE-F775-4977-8557-275F7909166C":F /l
    processed file: V:\VirtualMachines\Virtual Machines\1AF87BDE-F775-4977-8557-275F
    7909166C
    Successfully processed 1 files; Failed processing 0 files
    X:\>icacls "V:\VirtualHardDrives/Test Security Settings.vhd" /grant "NT VIRTUAL
    MACHINE\1AF87BDE-F775-4977-8557-275F7909166C":F /l
    processed file: V:\VirtualHardDrives/Test Security Settings.vhd
    Successfully processed 1 files; Failed processing 0 files

    After which I was able to connect to the VM and start it.

    What do you think of the following as a VM backup strategy:

    Backup the security settings:
    icacls V:\VirtualMachines\* /save X:\VMSecuirtySettings /T
    icacls V:\VirtualHardDRives\* /save x:\HDSecuritySettings /T
    icacls C:\ProgramData\Microsoft\Windows\Hyper-V\* /save x:\HVSecuritySettings /T
    Backup the Virtual Machines and Snapshots:
    xcopy "V:\VirtualMachines\*.*" "X:\VirtualMachines\" /D /E /V /C /I /Y
    Backup  the Virtual Hard Drives:
    xcopy "V:\VirtualHardDrives\*.*" "X:\VirtualHardDrives\" /D /E /V /C /I /Y
    Backup the symbolic links (Virtual Machines and Snapshots):
    xcopy "C:\ProgramData\Microsoft\Windows\Hyper-V\" "X:\Hyper-V\" /D /E /V /C /I /Y

All Replies

  • Saturday, April 25, 2009 11:39 AM
     
     
    I restore these kind of security settings with ICACLS.exe on the command-line.
  • Saturday, April 25, 2009 3:28 PM
    Moderator
     
     
    The simpleest - get it done and get going - answer is to create a new VM using the existing VHD - and point it to the place where you restored the VM.

    This will set up a new security GUID for the VM and its components, but it will also get you up and running quickly.

    Brian Ehlert (hopefully you have found this useful)
  • Saturday, April 25, 2009 6:08 PM
     
     
    Thanks.  I've already concluded that I have to do that for all of the VMs on this machine.

    I've also concluded that I have to change the backup strategies for the VMs.

    I ran a test of creating a new VM with a new VHD, deleting the VM and then creating a new one with the original VHD.  While the Hyper-V Manager deletes the xml file and the empty directory,  both old GUID and the new one are attached to the VND.  The old one says the account is missing.  I think that's a bug as I can see no reason for leaving the old GUID attached to the security profile of the VHD.

    It appears that Hyper-V sets up some hidden security objects.  Time to start digging.
  • Saturday, April 25, 2009 6:18 PM
    Moderator
     
     
    Each VM is represented by a GUID entity.

    There is a correcponding GUID security account that is created for each VM. 
    There are many reasons for this, can be thought of as similar to encapsulating the VM within an entity or security context.

    Simply backing up the files that represent a VM and restoring them neglects to handle this security entity.
    This is why many decide that it is easier to backup as you have and then on restore they actually create a new VM, and impose the settings of the backed up VM.

    Remember, these secirity identifies are unique to a host, they are local.  Thus if you restore to another host, you would need to generate new ones in the security DB of the new host (or register them).

    The model is not the same as VirtualPC or Virtual Server.

    Brian Ehlert (hopefully you have found this useful)
  • Monday, April 27, 2009 2:47 AM
    Moderator
     
     Answered

    Hi,

     

    You can use the icacls command to grant the permission:

     

    Grant full access to the virtual machine’s security identity using the command:

     

    icacls "%SYSTEMDRIVE%\ProgramData\Microsoft\Windows\Hyper-V\Virtual Machines\befde5dd-dc82-4575-9ca7-57625301ccb9.xml" /grant "NT VIRTUAL MACHINE\befde5dd-dc82-4575-9ca7-57625301ccb9":F /l, then you should be able to run the VM properly.

     

    Note: Please replace the “befde5dd-dc82-4575-9ca7-57625301ccb9” with the GUID of the specific VM you want to grant.

     

     

    Best regards,

    Vincent Hu

     

     

  • Monday, April 27, 2009 3:10 AM
     
     
    Each VM is represented by a GUID entity.

    There is a correcponding GUID security account that is created for each VM. 
    There are many reasons for this, can be thought of as similar to encapsulating the VM within an entity or security context.

    Simply backing up the files that represent a VM and restoring them neglects to handle this security entity.
    This is why many decide that it is easier to backup as you have and then on restore they actually create a new VM, and impose the settings of the backed up VM.

    Remember, these secirity identifies are unique to a host, they are local.  Thus if you restore to another host, you would need to generate new ones in the security DB of the new host (or register them).

    The model is not the same as VirtualPC or Virtual Server.

    Brian Ehlert (hopefully you have found this useful)
    I follow this in general but am a little confused about the specifics.

    In the begining of time, GUIDs were introduced as a unique id across machines.  If I remember correctly -- and I am hazy on this -- they include the MAC address as part of the hash to make them unique not only on the machine but across machines.  This may be a problem within virtual machines as the MAC addresses are artifical but should not be a problem at the top -- server -- level running on the physical machine.

    You mentioned generating new ones in the security DB of the new host or registering them?  Does this mean there might be a programic way to recreate the security entiry associated with the VM's GUID and then attach it to the VM and the VHD in the new environment or when restoring into the old one?  If so where one might find some documentation and, hopefully, sample code?

    The Offline Virtual Machine Servicing Tool 2.0.1 talks about servicing thousands of  virtual machines stored for months at a time in a number of libraries.  

    The tool uses “servicing jobs” to manage the update operations based on lists of existing virtual machines stored in VMM. Using Windows Workflow Foundation technology, a servicing job runs snippets of Windows PowerShell™ scripts to work with virtual machines. For each virtual machine, the servicing job:

    • “Wakes” the virtual machine (deploys it to a host and starts it).
    • Triggers the appropriate software update cycle (Configuration Manager or WSUS).
    • Shuts down the updated virtual machine and returns it to the library.

    The deployment process appears to require the creatiion of the GUID security object on the host -- is that correct?

    BTW, I still think not removing the old GUID security object from the VHD when the virtual machine is deleted is a bug.

    Edit:
    There is still a need to backup the VM itself if it contains any non-standard information.  The export process might be used for this but it won't export to a network drive.

    • Edited by saberman Monday, April 27, 2009 3:14 AM Added additional comment
    •  
  • Monday, April 27, 2009 2:50 PM
    Moderator
     
     
    In this case the GUID has nothing to do with the MAC - that is a different property of the VM (entity or object).

    The GUID is the identifier of the VM object within its host.
    (XenServer and Xen also do this same type of representation)
    In fact, GUIDs are used all over the place, to represent all kinds of objects under the hoods of many pieces of software.

    Vincent and zunebug have mentioned icacls.  Give it a look and see what it can do for you.  If it meets your needs.

    Export must go to a local drive.  This, again, is due to security settings.  As the VMMS.exe (the virtual machine management service) is actually performing the export and it resides in the system security context.  When you login, you reside in your user account security context.

    I cannot comment on the Offline VM Servicing tools as I have not had a chance to play with it.
    But is requires SCVMM and the SCVMM library is the storage location that is being referred to.  SCVMM is all driven by PowerShell.  That is where PowerShell comes in and where the Library concept comes in - the VM must be "stored" in the SCVMM library, growing crusty, stale, and out of patch compliance.





    Brian Ehlert (hopefully you have found this useful)
  • Monday, April 27, 2009 2:50 PM
    Moderator
     
     
    In this case the GUID has nothing to do with the MAC - that is a different property of the VM (entity or object).

    The GUID is the identifier of the VM object within its host.
    (XenServer and Xen also do this same type of representation)
    In fact, GUIDs are used all over the place, to represent all kinds of objects under the hoods of many pieces of software.

    Vincent and zunebug have mentioned icacls.  Give it a look and see what it can do for you.  If it meets your needs.

    Export must go to a local drive.  This, again, is due to security settings.  As the VMMS.exe (the virtual machine management service) is actually performing the export and it resides in the system security context.  When you login, you reside in your user account security context.

    I cannot comment on the Offline VM Servicing tools as I have not had a chance to play with it.
    But is requires SCVMM and the SCVMM library is the storage location that is being referred to.  SCVMM is all driven by PowerShell.  That is where PowerShell comes in and where the Library concept comes in - the VM must be "stored" in the SCVMM library, growing crusty, stale, and out of patch compliance.





    Brian Ehlert (hopefully you have found this useful)
  • Tuesday, April 28, 2009 10:38 PM
     
     

    icacls "%SYSTEMDRIVE%\ProgramData\Microsoft\Windows\Hyper-V\Virtual Machines\befde5dd-dc82-4575-9ca7-57625301ccb9.xml" /grant "NT VIRTUAL MACHINE\befde5dd-dc82-4575-9ca7-57625301ccb9":F /l, then you should be able to run the VM properly.

     

    Note: Please replace the “befde5dd-dc82-4575-9ca7-57625301ccb9” with the GUID of the specific VM you want to grant.

    Thanks.  Of course that generates a list of questions:

    Does that create the befde5dd-dc82-4575-9ca7-57625301ccb9 account as well as grant it access?

    Does that need to be done to the .VHD as well as the .XML?  They both have the GUID security reference as does the empty directories created in the Virtual Machines directory.

    How can I list the GUID security accounts?

    If I backup all of the ACLs in the Virtual Machines directory and sub directories and the ACLs for the VHDs can I just restore them or do I have to do something to recreate the GUID accounts as well?  If the GUID accounts need to be created how do I do that.

     

  • Wednesday, April 29, 2009 12:25 PM
     
     
    Hi Saberman,
    Please just try to run the command "icacls "%SYSTEMDRIVE%\ProgramData\Microsoft\Windows\Hyper-V\Virtual Machines\befde5dd-dc82-4575-9ca7-57625301ccb9.xml" /grant "NT VIRTUAL MACHINE\befde5dd-dc82-4575-9ca7-57625301ccb9":F /l" and you will get all the information you want.
  • Thursday, April 30, 2009 2:18 AM
     
     Answered

    The first time I tried it the command failed because I had deleteted the VM to be able testing the restore of a VM to a system that did not have it defined.  For example if the OS was restored from a point before the VM was defined.

    From: http://social.technet.microsoft.com/Forums/en-US/winserverhyperv/thread/3b0db540-cceb-4dd9-9b8a-3de6840bc03b

    I found information on the need to recreate the symbolic link first.

    So I ran:
    X:\>mklink "C:\ProgramData\Microsoft\Windows\Hyper-V\Virtual Machines\1AF87BDE-F
    775-4977-8557-275F7909166C.xml" "V:\VirtualMachines\Virtual Machines\1AF87BDE-F7
    75-4977-8557-275F7909166C.xml"
    symbolic link created for C:\ProgramData\Microsoft\Windows\Hyper-V\Virtual Machi
    nes\1AF87BDE-F775-4977-8557-275F7909166C.xml <<===>> V:\VirtualMachines\Virtual
    Machines\1AF87BDE-F775-4977-8557-275F7909166C.xml

    Then:

    X:\>icacls "C:\ProgramData\Microsoft\Windows\Hyper-V\Virtual Machines\1AF87BDE-F
    775-4977-8557-275F7909166C.xml" /grant "NT VIRTUAL MACHINE\1AF87BDE-F775-4977-85
    57-275F7909166C":F /l
    processed file: C:\ProgramData\Microsoft\Windows\Hyper-V\Virtual Machines\1AF87B
    DE-F775-4977-8557-275F7909166C.xml
    Successfully processed 1 files; Failed processing 0 files

    I could connect to the VM but I could not start it:

    [Window Title]
    Virtual Machine Connection
    [Main Instruction]
    The application encountered an error while attempting to change the state of 'Test Security Settings'.
    [Content]
    'Unnamed VM' failed to initialize.
    An attempt to read or update the virtual machine configuration failed because access was denied.
    [Expanded Information]
    'Unnamed VM' failed to initialize. (Virtual machine 1AF87BDE-F775-4977-8557-275F7909166C)
    'Unnamed VM' failed to read or update the virtual machine configuration because access was denied: General access denied error (0x80070005). Check the security settings on the folder in which the virtual machine is stored. (Virtual machine 1AF87BDE-F775-4977-8557-275F7909166C)
    [^] Hide details  [Close]

    The security settings for the XML file, the VHD file and the empty directory were not updated to include the 1AF87BDE-F775-4977-8557-275F7909166C account.

    I then ran:

    X:\>icacls "V:\VirtualMachines\Virtual Machines\1AF87BDE-F775-4977-8557-275F7909
    166C.xml" /grant "NT VIRTUAL MACHINE\1AF87BDE-F775-4977-8557-275F7909166C":F /l
    processed file: V:\VirtualMachines\Virtual Machines\1AF87BDE-F775-4977-8557-275F
    7909166C.xml
    Successfully processed 1 files; Failed processing 0 files
    X:\>icacls "V:\VirtualMachines\Virtual Machines\1AF87BDE-F775-4977-8557-275F7909
    166C" /grant "NT VIRTUAL MACHINE\1AF87BDE-F775-4977-8557-275F7909166C":F /l
    processed file: V:\VirtualMachines\Virtual Machines\1AF87BDE-F775-4977-8557-275F
    7909166C
    Successfully processed 1 files; Failed processing 0 files
    X:\>icacls "V:\VirtualHardDrives/Test Security Settings.vhd" /grant "NT VIRTUAL
    MACHINE\1AF87BDE-F775-4977-8557-275F7909166C":F /l
    processed file: V:\VirtualHardDrives/Test Security Settings.vhd
    Successfully processed 1 files; Failed processing 0 files

    After which I was able to connect to the VM and start it.

    What do you think of the following as a VM backup strategy:

    Backup the security settings:
    icacls V:\VirtualMachines\* /save X:\VMSecuirtySettings /T
    icacls V:\VirtualHardDRives\* /save x:\HDSecuritySettings /T
    icacls C:\ProgramData\Microsoft\Windows\Hyper-V\* /save x:\HVSecuritySettings /T
    Backup the Virtual Machines and Snapshots:
    xcopy "V:\VirtualMachines\*.*" "X:\VirtualMachines\" /D /E /V /C /I /Y
    Backup  the Virtual Hard Drives:
    xcopy "V:\VirtualHardDrives\*.*" "X:\VirtualHardDrives\" /D /E /V /C /I /Y
    Backup the symbolic links (Virtual Machines and Snapshots):
    xcopy "C:\ProgramData\Microsoft\Windows\Hyper-V\" "X:\Hyper-V\" /D /E /V /C /I /Y

  • Friday, July 23, 2010 2:01 PM
     
     

    Hi all - just recently transitioned from Vmware Server to Win2008 Server Hyper-V and have had this error message twice in the last week on routine reboots of the VM.  Each time, I solved by creating a new VM on a different host with the original vhd as a template.  Then I copied the new VM back to the original host.

     

    I tried the icacls command once and it did not work but will try again.  But my main objection is that this is happening at all.  This sort of behavior is not what I would expect from an enterprise-ready application.  In years with vmware server, I never failed to be able to reboot a VM.

     

    If my experience is any guide, then this must be happening in many installations.  Microsoft should modify the Hyper-V menus to execute a permissions repair rather than typing in this obscure command.  That's what Apple would do!

     

    Evan Bauman

    CIO - Buskop Law Group

    egbauman@gmail.com

  • Thursday, August 11, 2011 11:21 AM
     
     

    Spot on thanks so much. Had a server go down, I took the SAN attached the LUN to the other server, copied over the Virtual Machine and Snapshot xmls, ran that command and I was back in business.

     

     

    Thanks So much

     

    Aaron

  • Thursday, September 15, 2011 4:40 PM
     
     
    The simpleest - get it done and get going - answer is to create a new VM using the existing VHD - and point it to the place where you restored the VM.

    This will set up a new security GUID for the VM and its components, but it will also get you up and running quickly.

    Brian Ehlert (hopefully you have found this useful)

    This is the solution I used.  

    The KISS method works wonders.  Thanks!


    All Day
  • Thursday, March 08, 2012 2:31 PM
     
     

    This worked for me--with one extra step.  Setting the permission on the XML file permitted the VM to start up, but then it would fail with a nearly identical message complaining about the permission on the VHD files.  Running the same command against those files (instead of the XML files) fixed that problem and the machines started up properly.

    As an aside, creating a new VM with existing VHDs works as well--but it causes the MAC address for the machine to change (and I suspect other low-level GUIDs, like the SMBIOS GUID, which can mess up stuff like the SCCM Client.  Sometimes it matters, sometimes it doesn't.