- Windows Server 2008, 2008 R2, 2012, 2012 R2, 2016
After a total cluster failure occurs, or a node is removed from a cluster before it has been cleanly removed. When attempting to locally manage the host as a stand-alone Hyper-V server, you are unable to edit the live migration settings in Hyper-V Settings via Hyper-V Manager with the error
The IP/Subnet addresses shown on the form will be greyed out and you will be unable to edit the live migration network settings.
While you should ensure that you have performed a cluster clean-up on the host
Server 2012 +:
Clear-ClusterNode -Force -CleanupA
cluster node <hostname> /forcecleanup
This will not solve the live migration settings issue highlighted above.
- Close Hyper-V Manager on the management workstation
- On the hypervisor experiencing these symptoms (not necessarily the management console). Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Migration\NetworkSettings
- Underneath this key there will be a key for each entry shown on the Live Migration Settings screen. The keys will be named Network# e.g. Network0, Network1, Network2 and so on.
- Go through each of these Network# keys and locate the ‘Tags’ REG_MULTI_SZ. This will have a value of “Microsoft:ClusterManaged”
- Change the data value to “Microsoft:UserManaged”
- Complete the process for each Network# sub-key
- Restart Hyper-V Manager
You will now be able to add, edit and delete the live migration settings.
- Windows 7, 8.0, 8.1, 10
- Windows Server 2008 R2, 2012, 2012 R2, 2016
- DISM, MDT, SCCM, WAIK, WADK
I am a DVBLink user. DVBLink does not play nicely with Windows Service and consequently it wants to run on a client OS. This means that I have lots of server hardware running server Operating Systems and one device with 4 TV Tuners in it running Windows 10.
After modifying the registry of an off-line WIM image, after the initial image has been inflated onto the drive, the system blue screens (BSOD) at the first reboot with
The newly imaged system will now get stuck in a boot loop.
You have a corrupted registry.
There are a number of possibilities to explore first
Check that you haven’t deleted the contents of CurrentControlSet (reference machine prior to sysprep) or ControlSet001 (reference machine and WIM file) from the registry
Check that you haven’t deleted the SYSTEM file from C:\Windows\System32\Config (this is a hidden file and it has no file extension)
Finally, if you injected registry data into an offline WIM image, ensure that you did not create the Key .\CurrentControlSet in the C:\Windows\System32\Config\SYSTEM. CurrentControlSet is a virtualised key that is loaded and unloaded dynamically as part of the Windows boot proceess (it is actually a copy of ControlSet001). When the system goes through shutdown or a reboot, CurrentControlSet is cleared and ControlSet001 is copied in-place. If the key CurrentControlSet exists in the WIM file’s registry, Windows will present the CONFIG INITIALISATION FAILED blue screen of death as it is not expecting the CurrentControlSet key to exist at all.
To fix the problem, re-mount your image and from the SYSTEM container move any data from CurrentControlSet into ControlSet001 and then completely delete the key for CurrentControlSet
- Windows Vista, 7, 8, 8.1, 10
- Windows Server 2008, 2008 R2, 2012, 2012 R2, 2016
If you attempt to restore a Windows Server Backup or Windows Backup recovery image (system state) from a bootable recovery media (either DVD, USB or a recovery partition) you receive the following error message
Just to keep this simple. The limited amount of information available on-line on this error suggests that either the image is corrupt or you are having a network reliability issue.
These could be true. In my case, it wa the path length that I was using to recover the image from. I was recovering from
It turns out that the entire path must be 110 or fewer characters otherwise it will fail with the 0x80070001 error.
A simple fix is to temporarily create the path \\192.168.15.106\BackupFiles\WindowsImageBackup on your share and then copy the <hostname> folder into it. This worked in my case.
- Office 2007
- Office 2010
- Office 2013 (Enterprise)
- Office 2016 (Enterprise)
You’re one of the lucky people who has access to a version of Office that doesn’t need to use the awful “Click to Run” to perform the install. You are trying to use SCCM, Group Policy, a BAT file or some other remote invocation method to deploy Office from a source repository on a SMB file share.
Office starts to install, the installation looks like it is working and even one or two app’s appear on the start menu… before it unexplainably performs a roll back and uninstalls itself leaving your machine with no Office installation.
If you check the log files (in %temp% or c:\users\<user>\AppData\Local\Temp by default) you will find a Windows Installer Error 1635 entry listed before it commenced the rollback.
Windows Installer Error 1635 is “This patch package could not be opened. Verify that the patch package exists and is accessible, or contact the application vendor to verify that this is a valid Windows Installer patch package”.
If you are using SCCM, then you are probably attempting to execute this through the NT System account or via local admin.
Obviously you’ve checked the share permissions, perhaps even enabled a Null Session Share to allow anonymous access to the share… and it still doesn’t work. The client script is obviously executing successfully because the setup programme loads and runs for 10 minutes or more quite happily before erroring out.
Quite simply, save yourself a headache and script the process to call the Office setup.exe from the local machine rather than directly against the SMB Share. This will solve the problem. Something in line with the following will download the installer and files from the repository to the OS Temp directory, execute the installer process and then clean-up