The aim of this article is to create a slowly growing cheat-sheet of Hyper-V Errors and known fixes.
Errors without Error Codes
These errors are UI errors that do not provide a Hex Error Code / Win32 Error Code.
There was an error during move operation.
Migration operation on ‘<VM Name>’ failed.
See 0x80041024
There was an error during move operation.
Virtual machine migration operation failed at migration source.
Failed to create folder.
See 0x80070005
Errors with Error Codes
The following errors have error codes either stated on GUI error messages, as part of PowerShell error messages or in the Hyper-V event logs in Event Viewer.
0x80041024
Event ID: 16000
The Hyper-V Virtual Machine Management service encountered an unexpected error: Provider is not capable of the attempted operation (0x80041024).
One or both of the Hyper-V servers has an invalid or inaccessible IP address/network address on the “Incoming live migrations” list on the “Live Migrations” tab in Hyper-V settings
The live migration network is down, the/a cable is unplugged or faulty
0x80070002
Could not create backup checkpoint for virtual machine ‘<VM Name>’: The system cannot find the file specified. (0x80070002). (Virtual machine ID <VM GUID>).
Check that you have enough disk space on the volume to perform the VSS. If your volume is sub-15%, try using the Hyper-V Manager to change the snapshot directory to another volume – plug in an external NTFS formatted hard drive if you have to.
Check the permissions of the VHD stated in the error.
icacls “C:\Users\Public\Documents\Hyper-V\Virtual Hard Disks\<VHD File>” /grant “NT VIRTUAL MACHINE\Virtual Machines”:F
Check that you can manually checkpoint/snapshot the VM while it is running.
In Hyper-V Manager or in PowerShell, force a checkpoint on the VM and then delete it and wait for it to merge back. If this works, you are not having a physical VSS issue. If it fails, you need to troubleshoot this and not the WSB error.
Live Migrate the VM off of the current server and onto a different Hypervisor, attempt the backup here, then bring it back to the original server and try again. This process will reset the permissions on the VM file set. If you cannot live or offline migrate the VM, the you need to troubleshoot this and not the WSB error
Ensure that all VHDX files associated with the VM are on the same storage volume and not spread across multiple Volumes/LUNs (be it individual disks, logical RAID or iSCSI disks). If they are, move them to a common location and retry the operation.
If you are using a management console (not the local Hyper-V console to perform the migration. You must setup Kerberos Constrained Delegation for all of your Hyper-V hosts machine accounts in Active Directory.
Ensure that both NetBIOS and fully qualified DNS entries exist in the Constrained delegation (click the “Expanded” check box to verify this) e.g. myserver1 and mysever1.mydomain.local for both “CIFS” and “Microsoft Virtual System Migration Service”
For Hyper-V 2008, 2008 R2, 2012 and 2012 R2 “Trust this computer for delegation to specified services only” should be used along with “Use Kerberos only”
For Hyper-V 2016 and 2019 or a mixed environment “Trust this computer for delegation to specified services only” must be used along with “Use any authentication protocol”
0x8007274C
Event ID: 20306
The Virtual Machine Management Service failed to establish a connection for a Virtual Machine migration with host ‘<Hypervisor FQDN>’: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. (0x8007274C).
The Live Migration firewall rules have not been enabled in Windows Firewall (or your third party firewall). This is especially easy to forget on Server Core and Hyper-V Server installs.
No DNS server(s) or invalid DNS server(s) have been specified on the network configuration for the hypervisor
Specified DNS server(s) are unreachable
An intermediate firewall or IDS blocked the request
This article discusses a situation whereby you want to monitor/mirror/sniff network port traffic on a Hyper-V Parent Partition inside on of its own child VM’s.
Why would you need to do this?
Under a traditional architecture you have the flexibility to tell your switch to mirror all traffic into or out of Port 6 onto Port 21. You then connect a laptop to Port 21 and promiscuously monitor the traffic coming into that port. Under a modern Converged/Software Defined Network architecture, this will not work.
In a modern Converged Fabric design, physical NICs are teamed. The parent partition on the hypervisor no-longer uses the physical NICs, but logically uses its own synthetic NICs for data transfers.
Link Aggregation/LCAP/EtherChannel will split the traffic at the switch
Teaming/LBFO will split the traffic at the hypervisor
Data security will fire a red flag as you will be monitoring too much unrelated traffic
If you combine them, you will overload the monitoring Port with aggregated traffic, causing performance issues and packet loss
You may impact the performance of tenant VM’s and mission critical services
Fortunately the Parent Partitions own Virtual NICs are identical to the vNICs in any Hyper-V virtual machine. Consequently, you can use the same Hyper-V functionality on the Parent Partition as you would any VM.
Requirements
In order to sniff traffic on the Parent Partition you must ensure the following:
The Parent Partition and the VM must be connected to the same Virtual Switch
The “Microsoft NDIS Capture” extension must be enabled on the Virtual Switch (this is enabled by default)
The monitoring VM should have 2 vNICs. The vNIC used to monitor traffic should be configured onto the same VLAN as the vNIC on the Parent Partition. The monitoring NIC should have all of its service and protocol bindings disabled to ensure that only port mirrored traffic is appearing in the WireShark logs
Wireshark, Microsoft NetMonitor or another promiscuous network traffic monitor
If you are in a corporate environment, ensure that you have approvals from your Information Security team. In some jurisdictions port sniffing can be considered an offence
Enabling Port Sniffing
You cannot enable Port Sniffing on the Parent Partition using the Hyper-V Manager GUI. Open PowerShell on/to the Parent Partition
Execute Get-NetAdapter
Identify the name of vNIC that you will sniff traffic to/from e.g. vEthernet (Management)
Taking only the value inside the parenthesis "Management" enter the following command
Substituting WireSharkVm for the name of your monitoring VM. Execute Get-VMNetworkAdapter 'WireSharkVm'
Identify the MAC Address of the vNIC’s that you will use to receive the Port Mirror from the Hyper-V host and enable it as the recipient for the mirror
If the Parent Partition and VM vNICs are in the same VLAN. You should now be able to sniff traffic inbound to / outbound from the Parent Partition.
Disabling Port Sniffing
When using Port Mirroring, remember that it consumes CPU time and network resources on the hypervisor. To disable the port mirror, repeat the above commands substituting ‘None’ as the key-word for the PortMirroring parameter e.g.
This article discusses a method of eliminating phantom “ms-resource:AppName/Text” entries on the Windows 10 Start Menu. You may see these after upgrading Windows 10 to version 1903 in an “other” group at the bottom of the Start Menu.
What are “ms-resource:AppName/Text” entries?
A database is used to store information on user-available ModernApps and its contents merged with traditional apps (.lnk files) when the start menu is opened by a user.
The “ms-resource:AppName/Text” reveals a corrupt/orphaned entry in the database. As part of this, lookups are performed to C:\Users\<username>\AppData\Local\Packages and/or C:\Windows\SystemApps to load the app’s manifest.xml file. The manifest file is used to query for the Icon, life tile instructions and the multilingual label used on the start menu.
If the database record exists, but the application itself no longer does – due to a crash during uninstall or the user being offline when an administrator removed the app. “ms-resource:AppName/Text” will appear until such time that Windows validates the contents of the database. This usually during the next update to the “Start Menu” app itself, or an OS upgrade.
Ensure App Uninstallation
A common reason for this occurring is:
The user has never run the app to install it into their user profile
The app is removed from AppxProvisionedPackages in C:\Windows\SystemApps by an administrator. This prevents self-repair
The app is removed from ‘All Users’ on the system, however the database entry remains in one or more local user profiles
If there are remnants of the app in Get-AppxPackage or Get-AppxPackage -AllUsers, you must remove the entries first. This is because the entry will be re-written to the Start Menu database after it is reset.
Once the app has been removed from the local user account, ‘all users’ and the provisioned apps repository. You can reset the database.
Reset the Start Menu database
There are several ways to do this. This fix runs in the local user context and uses a “bludgeoning” approach to solving the problem.
Paste the following code into a PowerShell window. It will error, it will not be pretty but it will remove the phantom entry – provided that you have genuinely uninstalled the app.
If you are paying attention, yes, the above is repeating itself several times. This is intentional.
What does it do?
Very simply the above PowerShell sample:
Crashes the Windows Shell (Windows Explorer)
Looks up the version number of the Windows 10 Start Menu app (“Microsoft.Windows.StartMenuExperienceHost”)
Uses the version number to construct the path to the location of the Start Menu database
Deletes the database
Return to 1
Repeat…
Start Windows Explorer
The code repetition prevents explorer.exe from being auto-recovered by the WinLogon watchdog. If explorer.exe is running, it will fail to delete the database. By repeatedly running, it will eventually brute-force explorer.exe closed, perform the deletion and restart explorer.exe on its own.
Explorer.exe re-scans the local system/user to inventory apps when it starts and a new database created without the phantom app.
WorkFolders allows you to perform policy based file HTTPS synchronisation between corporate servers and BYOD devices or teleworker devices. This article discusses a workaround to a problem where an anonymous sync error appears on a directory despite all of its contents synchronising successfully.
Outline of the Problem
Assume the following directory structure
C:\Users\CompanyUser\WorkFolders\Documents\WorkFolders Test
The following files/folders are present within WorkFolders Test:
WorkFolders Test\Problem Folder
WorkFolders Test\Problem Folder\File in Problem Folder.docx
WorkFolders Test\This file is OK.txt
Windows Explorer will display a Green circle with a tick for file/folder object that is synchronised and a Red circle with a cross for a faulted file/folder. After synchronising, the sync results will display as follows:
WorkFolders Test\Problem Folder [CROSS]
WorkFolders Test\Problem Folder\File in Problem Folder.docx [TICK]
WorkFolders Test\This file is OK.txt [TICK]
No errors are displayed in the Control Panel WorkFolders applet. There are no related errors in the clients WorkFolders Management/Operational Event Viewer logs. No relevant errors are present in the file servers SyncShare Operational/Reporting logs.
The parent folder shows that its sub-folder has a sync errorThe contents of the error’d folder are however correctly synchronised.
Analysis
Although WorkFolders is indicating that the issue is being caused by the “Problem Folder” directory. The issue is being caused by the “File in Problem Folder.docx”.
The following symptoms will be true:
Renaming “Problem Folder” will not fix the issue
Altering the filename of “File in Problem Folder” will not fix the issue
Changing the “File in Problem Folder.docx” file extension (e.g. to .txt) will not fix the issue
Opening and saving the “File in Problem Folder.docx” will not solve the issue
Moving “File in Problem Folder.docx” out of “Problem Folder” will clear the sync error, but the error will immediately migrate to the new location
Rebooting the client computer will not help
Restarting the server will not help
The file does not have any connected temp files or lock files associated with it in the client file system
There is nothing wrong with the file itself. It is not corrupt, pay-loaded with a virus or violating any policy. It is my (unproven) belief that the record for the file in the WorkFolders synchronisation database is corrupt. Performing any of the above steps will not alter the record in the WorkFolders client database, thus the problem cannot be ameliorated.
Fixing the problem
One you have identified the problem file(s). You can use one of the methods below to correct the error.
Save the file as a completely new file
Open the file in its associated editor (e.g. Microsoft Word for docx files)
File > Save as…
Save the file in its original location, but with a different file name (do not overwrite the original)
Delete the original file
Allow WorkFolders to re-sync
Rename the new file as required
This approach is easy for an end-user to perform, but can be very time consuming if you are troubleshooting a large number of such issues. It requires you to know which file is causing the problem in the first place.
Compression
Compress the file using Windows Compressed folders (Right click > Send to… > Compressed (zipped) file)
Delete the original file
Wait for the folder to re-sync and clear the error
Extract the original file from the zip back into the desired location
This method will create a new record in the WorkFolders synchronisation database and the error will not reappear. You can use the technique to fix an entire folder structure without having to first identify the problem file. It is also easy for an end-user to perform.
Move the file
Move the file outside of the WorkFolders monitored file system. For example, move the file to C:\ or into the Recycle Bin
Allow the original folder to re-sync and clear the error
Return the original file to its original location and allow it to re-sync
Again, this method will create a new synchronisation record. In a managed environment this may be harder for an end-user to perform due to permissions. It is however easier for an administrator to perform as you can cut/paste the entire file structure out and then back into the WorkFolders sync root.
If you use this method, remember to move it to a location within the same drive letter. If you do, the move will preserve permissions, file dates and will not physically copy the underlying data to the new location (just update the MFT).
