Hyper-V Resolving Event ID 4096

Over the break I’ve been taking over Christmas, one of my goals was to move the remainder of my Virtual Server “production” VMs across to Hyper-V. But when nearing completion, I noticed that Server Manager was reporting a role error:

Looking at the detail of the event logs, it was Event ID 4096 from Hyper-V-Config saying that The Virtual Machines Configuration {GUID} at ‘{Directory}’ is no longer accessible: The system cannot find the path specified. (0x80070003)

This is a pretty common error many people hit, and in my case it was due to some rearranging of directories and moving virtual machines around until I had it “just right” in terms of how I like to set my own servers up. By personal preference (nothing more), I like to keep the configurations, snapshots and VHDs for my virtual machines under a single directory on a per VM basis – in my case v:\virtual machines. However, when playing earlier with my new server, I’d been using the v:\vms directory (hence the specific error in the screenshot below).

So in Hyper-V Manager, under Hyper-V Settings, I enter V:\Virtual Machines in the text boxes for both Virtual Hard Disks and Virtual Machine Configuration files.

 

Then, when using the New Virtual Machine wizard, I check “Store the virtual machine in a different location” but keep the default directory set above, and get to the Connect Virtual Hard Disk step, the wizard populates the default directory for a new VHD in a sub-directory under V:\Virtual Machines named the same as the Virtual Machine.

If you examine the directory structure of V:\Virtual Machines\Test after completing the wizard, you end up with this (if you also take a snapshot)

Your VHD is in the main directory, and the configuration and snapshot data-root are under the Virtual Machines and Snapshots subdirectories under “Test” (or whatever you name your virtual machine). In other words, everything for that virtual machine is in a single location which was the primary intent.

Anyway, (as I frequently do in my blog posts), I somewhat digress. Back to the Event ID 4096 which indicated there was a problem with V:\VMs, the original location I was using when moving virtual machines across from Virtual Server.

If you navigate to \ProgramData\Microsoft\Windows\Hyper-V\Virtual Machines on your system drive (note that ProgramData is a hidden directory), you’ll notice that there are a number of symbolic links to configuration files. There are two in the screenshot below (one being highlighted) which points to the V:\VMs\… directory.

So it’s a simple case of very carefully deleting that or those links (just use the “del” command) which refer to the old directory, and cycling the VMMS service (net stop vmms, then, net start vmms). After this, the error will no longer be logged. Please be extremely mindful not to delete links referring to VMs you want to keep! Onwards with the rest of the migration now…

Cheers,
John.

Comments

• Anonymous
  January 01, 2003
  Chris - what build number of Windows 7, and are you logging on with a smartcard? (I assume you are also remotely managing a server.....? If so, what is the server build - 2008, or R2, and if R2, which build number?) Thanks, John.

• Anonymous
  January 01, 2003
  Chris - is it possible you are hitting http://support.microsoft.com/default.aspx?scid=kb;EN-US;967902? Alternately, under Hyper-V Settings in Hyper-V Manager, have you flipped the "Use default credentials..." checkbox?  It shouldn't be necessary to import a certificate from the server into the Win7 client.... Thanks, John.

• Anonymous
  January 05, 2009
  Hey John, I ran into this a while back and I wrote a little powershell script to delete the broken links. It uses James O'Neill's Hyper-V library on codeplex http://www.codeplex.com/PSHyperv, so you will need that loaded into your shell. -Andy

---

. .Hyperv.ps1 $VMPath = "C:ProgramDataMicrosoftWindowsHyper-VVirtual Machines" $FileNames = Get-ChildItem $VMPath | select Name $VMs = Get-VM | Select Name foreach ($FileName in $Filenames) { foreach ($VM in $VMs) { #$VM.Name if ($FileName.Name.split(".")[0] -match $VM.Name) { $Match = "True" } } if (-not $Match) { Write-Host "Deleting $($FileName.Name)" -foregroundcolor Red Remove-Item "$($VMPath)$($FileName.Name)" } else { Write-Host "$($FileName.Name) is Good!" -foregroundcolor Green } $Match = $Null }

• Anonymous
  January 12, 2009
  This is a great post and was really helpful! If only the Hyper-V team decided to add this event ID to their online help documentation. And I would assume that the UI would expose these stray hyper v configs and let the user delete them without messing with the config files. Alas, Wishful thinking???

• Anonymous
  March 09, 2009
  The comment has been removed

• Anonymous
  March 10, 2009
  The comment has been removed

• Anonymous
  March 10, 2009
  Never mind.  In WIndows 7 X32, "Install Certificate" works fine.. but it doesn't in x64.  Using the certificates MMC plugin, I was able to add the certificate to the local computer and that fixed it.

• Anonymous
  March 10, 2009
  Nope, not running into expired certificate; using a Hyper-V Server R2 (Beta) candidate for testing purposes only; certificate is valid through 3/10 or something.   It just doesn't like publisher.  I ran the HVRemote script to reset; I've replicated this, it only seems to occur within the x64 version, this never happens in x32.. so, I'll submit it in as a bug for now.. :)  But it's fixed after an import.

• Anonymous
  July 22, 2010
  Thank you very much!!!! Great information, and super helpful. Cheers!

• Anonymous
  September 18, 2010
  Update the patch in the hyper - v host server and restart to solve the certificate expiration issue support.microsoft.com/.../967902

• Anonymous
  May 30, 2014
  Thank you for this post.
  In my case the event ID 4096 was refered to Snapshot configuration, so i deleted the symlink both in C:ProgramDataMicrosoftWindowsHyper-VSnapshots and C:ProgramDataMicrosoftWindowsHyper-VSnapshots Cache
  Thanks