I had a VM that I had restore in my environment that failed. I had to rebuild the VM and started backing up again. But since then, I have had issues with the checkpoints and kept getting these errors in my backup logs:
So. I go into Hyper-V Manager and try to manually delete the checkpoint. I got the same error:
Virtual machine failed to generate VHD tree: ‘Catastrophic failure'(‘0x8000FFFF’)
So, I go and find a blog post explaining how to manually export the checkpoint files to a new VHD and recover the VM in its current state properly so that my backups can start again. Here are the steps:
NOTE: This process will merge changes so previous checkpoints will no longer be available for rollback.
Export the last checkpoint of the VM:
Locate the most recent snapshot and select it. Click Export from the actions menu. Export the VM to a new location. Shutdown the original VM. Once the export completes you will have a new merged vhdx!
Replace the Offending VM with the Exported VM:
Click Import Virtual Machine. The VM will have the name of the snapshot. Power the imported VM on and validate it’s working as desired. Power Off the VM. Once satisfied with the new VM, delete the offending VM and it’s disks. Rename the newly imported VM. Place the virtual disks in their original spots and reconfigure the new VM to go to those locations. Now you’re VM is updated and fixed!
I luckily had enough disk space on my drive to export the VM since it is my WSUS server. I probably could have just deleted the WSUS repository disk, but I did not want to chance it since the other was working. Things are back to their normal, POSITIVE state!
POSITIVE THOUGHTS AND ACTIONS STAY! HAPPY TROUBLESHOOTING!
I’ve been currently assisting with onboarding at my new Full Time Contractor position at Microsoft. All of the new FTCs received laptops and needed to have the newest build of Windows 10 installed. The issue was that all of our laptops came with Windows 10 Professional and we needed to upgrade them to Enterprise edition.
After finding a working key for Enterprise Edition, we were still having issues joining the MS Azure domain so that we could get all of the needed software properly to being onboarding with Microsoft.
So, after going through a couple of re-images of my laptop with some failures attached to that, I finally was able to get the process down so that time would not be waisted for the oncoming new hires once they received their laptop. The issue was getting the correct build of Windows 10 and getting the proper apps installed in an efficient manner. Since the onboarding process was quickly moving, I needed to find a way to help streamline the process so the others would not have to go through all the mess I went through to get everything setup.
So, I began looking for a way to create a customized ISO for the build that would already have apps, settings, and customizations installed. I found this great article that details the process. I wanted to re-post this article here showing the steps I took to create the customized image by creating a VM in Hyper-V and then converting that completed image to an ISO that could be downloaded and utilized for the installation.
Creating a customized ISO image with pre-installed software and no user accounts
A generalized ISO image without any pre-set user accounts, with pre-installed software, desktop, File Explorer and Start customizations will be created.
All customizations and personalization will automatically be applied to all new user accounts
Clean install will perform a normal OOBE, asking for regional settings, initial user and so on
This ISO will be generalized meaning it is hardware independent and can be used to install Windows on any computer capable of running Windows 10, regardless if the machine is a legacy BIOS machine with MBR partitioning, or a UEFI machine with GPT partitioning
The ISO image will be bootable on both BIOS / MBR and UEFI / GPT systems
NOTE: This post will show how to use a virtual machine to create the ISO. All virtual machine references and instructions in this tutorial apply to Hyper-V, available in Windows 10 PRO, Education and Enterprise editions. Oracle VirtualBox and VMware users might need to consult their preferred virtualization platform’s documentation if instructions can’t be used as is. Everything in this instruction can be made in each edition of Windows 10 (in Home and Single Language editions using a third party virtualization platform) with native Windows tools and programs, apart from Windows Deployment and Imaging Tools, part of Windows 10 Assessment and Deployment Kit (ADK) needed later in the post. The ADK is a free native Microsoft tool, downloadable directly from Microsoft. If you will do this on a Hyper-V virtual machine (which is the recommended method), make sure to set the new virtual machine to use Standard Checkpoints instead of default Production Checkpoints. You can do this in virtual machine’s settings:
This method will produce an ISO image which can be compared to any original Windows 10 ISO you download from Microsoft, apart from the fact that it already contains pre-installed software according to your choice. It will also contain a customized and personalized default user profile, the base Windows uses whenever a new user profile will be created.
A customized default user profile means that whenever a new user account is created, all customizations (Start tiles, File Explorer & desktop icon and view settings, colors, wallpaper, theme, screensaver and so on will be applied to new user profile instead of Windows defaults.
Installation using this ISO will take somewhat longer than using a standard ISO because it not only contains full Windows setup, but also the pre-installed software. Notice that depending on how much space pre-installed software takes, you might not be able to burn this ISO to a standard 4.7 GB DVD disk but have to use a dual layer disk or a USB flash drive instead. My customized image came out to be about 8.5 GB in size.
The ISO created will include no user profile folders, personal user data and files.
This ISO image can be used on any hardware setup capable of running Windows and can be shared, subject to people you share the ISO with have valid licenses and / or activation keys for both Windows 10 and pre-installed software.
System Preparation Procedure
Download the Windows ISO Installation tool from Microsoft
Use this TOOL to download the ISO and create the installation media
Install Windows 10 on your VM using the downloaded ISO
NOTE: The normal Windows Download from the link above will download Windows 10 Professional. You will need a key for the installation to upgrade to Enterprise Edition and you will need to be able to activate the copy of Windows to be able to save the customizations you create for your ISO.
Boot into Windows 10 and do the following:
Activate the Windows Edition your are installing with your key. You will require internet connectivity. I needed Enterprise Edition so I changed the Product Key In Settings to upgrade it from Professional.
Install your preferred software, customize and personalize Windows, remove / add Start tiles as you wish, and set your preferred group policies (group policies not available in Home and Single Language editions). Do not run any program you install!
Update all software and run Windows Update to get all the latest updates for the image.
Notice that software installed now will be included in ISO install media, and will be pre-installed for all users on each computer you install Windows to using this custom ISO.
NOTE: If Windows on your reference machine is not activated, you cannot personalize it. In this case you need to modify Windows theme (wallpaper, screensaver, colors, sounds) as you wish on another, activated Windows 10 machine, save the theme as a theme file, copy it to inactivated reference machine and apply (double click). Also notice that Edge as well as other UWP apps do not work when signed in to built-in admin account. If you need a browser to download software you have to use a third party browser or Internet Explorer. IE can be started from Run dialog by typing iexplore and clicking OK.
Open an elevated command prompt and enter the following:
Windows will now restart in Audit Mode using built-in administrator account. You will see a Sysprep prompt in the middle of display:
Open Notepad, paste the following code to it, make the necessary changes to customize the installation, and save it as File name: unattend.xml (exactly this name!) Save as type: All files (important!) Save in folder:C:\Windows\System32\Sysprep
When Sysprepping with the Generalize switch, which we will soon do, the component CopyProfile being set to be TRUE in answer file has a small issue or rather a small inconvenience: it leaves the last used user folders and recent files of built-in admin to end user’s Quick Access in File Explorer.
To fix this, we need to reset Quick Access to default whenever a new user signs in first time. It requires the need to run a small batch file at first logon of new user, and then remove the batch file itself from user’s %appdata% so Quick Access will not be reset on any subsequent logon.
To do this, open an elevated (Run as administrator) Notepad (Notepad must be elevated to save in system folders), paste the following code to it, save it as: File name: RunOnce.bat (or any name you prefer, with extension .bat) Save as type: All files (important!) Save File in folder:%appdata%\Microsoft\Windows\Start Menu\Programs\Startup
Delete all existing user accounts and their user profile data (Option One in this tutorial)
You are currently signed in using Windows built-in administrator account. In File Explorer, open C:\Users\Administrator folder and check that all user folders are empty deleting all possibly found content
Run Disk Clean-up, selecting and removing everything possible (tutorial)
When the disk has been cleaned, create a checkpoint of the VM from Hyper-V Manager. Right Click VM > Click Checkpoint
In Sysprep dialog still open on your desktop, select System Cleanup Action: Enter System Out-of-Box Experience (OOBE), select Shutdown Options: Shutdown, select (tick the box) Generalize, click OK:
Sysprep will now prepare Windows, shutting down machine when done. LEAVE THE VM OFF AND DO NOT RESTART IT! Now, we continue to the Image Creation section.
Image Creation Procedure
On your Hyper-V Host machine, open Disk Management
Select Attach VHD from Action menu:
Browse to and select your reference virtual machine’s VHD / VHDX file. If you have any checkpoints (AVHD / AVHDX files) created on this vm, select the one with most recent time stamp. Note that you have to select show all files to be able to see checkpoint AVHD / AVHDX files:
Select the check box labeled Read-only (this is very important!), then click OK:
IMPORTANT: Forgetting to select Read-only will especially when mounting a checkpoint AVHD / AVHDX file make it unusable for Hyper-V! You will NOT be able to boot your VM and could corrupt it should you have write access on the mounted VHDX file. Windows mounts the virtual hard disk, and all of its partitions, as separate disk. In case of an MBR disk it even mounts the system reserved partition.
NOTE: In the above picture the Windows system partition for the reference VM is drive K:
Open the Windows system partition VHD to be sure that’s the one where Windows is installed, note the drive letter your host assigned to it.
Open an elevated Command Prompt, enter the following command to create a new install.wim file:
NOTE: D:\install.wim path in this case is the drive and directory where you want to save the image file. K:\ path is the capture path with subfolders of the drive you want to image FROM
NOTE: The name given in /name switch in above command is irrelevant as we will name the ISO later on, but is needed for the command to run. Use any name you want to for the switch parameter. The image process will take time, go get something to eat as I did. On my high end Hyper-V server this takes over 20 minutes, the first half of it without showing any progress indicator whatsoever. DISM works somewhat faster if you don’t use optional switches /checkintegrity and /verify but it is not recommended that you to create install.wim without checking its integrity and verifying it.
When completed capturing the image, detach the VHD / VHDX or AVHD / AVHDX file from host by right clicking it in Disk Management and selecting Detach VHD:
ISO Image Creation Procedure
Mount the original Windows 10 ISO you downloaded in the first step to a Virtuial Drive on your Hyper-V Server Host.
Copy its contents (everything) to a folder you create on one of your Hyper-V host’s hard disks:
I named the folder ISO_Files and placed it on the D: drive where I had created the image from the previous section. Alternatively, you can copy the contents of a created Windows 10 install USB or DVD to the ISO_Files folder.
Browse to your custom install.wim created earlier in previous section. Copy it to Sources folder under the ISO_Files folder, replacing the original install.wim in that directory:
IMPORTANT: If the ISO you used when copying the files to the ISO_Files folder has been made with Windows Media Creation Tool, the ISO_Files\Sources folder contains an install.esd file instead of install.wim. In this case you will naturally not get “File exists” prompt. Simply delete the install.esd file and paste your custom install.wim to replace it.This will help reduce the overall size of the ISO and not confuse the installation process when ran.
Now, we download the latest Windows Assessment and Deployment Kit(ADK)for Windows 10: Windows ADK downloads – Windows Hardware Dev Center The full download for the ADK is about 7.5 GB but luckily we only need the Deployment Tools portion. So, unselect everything else except Deployment Tools and click Install:
Once completed, you should have a folder within your start menu for the ADK Tools Installation under the folder Windows Kits. Start the Deployment and Imaging Tools interface program by Running the Program as an Administrator:
At the command prompt, type cd\ to bring your prompt to the root of the folder path you are on.
Type the following command to initiate creation of the ISO image file:
Replace three instances of d:\iso_files with the path to the ISO_Files folder where you copied Windows installation files. Notice that this is not a typo: first two of these instances are typed as argument for switch -b without a space in between the switch and argument. This is to tell the oscdimg command where to find boot files to be added to ISO.
Replace d:\14986PROx64.iso with the path where you want to store the ISO image. This is where you also name the ISO file what you want the file name to be.
Although the command seems a bit complicated, everything in it is needed. For more information about the oscdimg command line options, see: Oscdimg Command-Line Options
You now have a completed ISO image ready for distribution to your machines. The overall process took me about 4 hours to complete with all the customizations that I did. Thanks again to Ten Forums for the article. I have provided references below for your convenience as well.
The sheer craziness of it all! I noticed that my clocks were off on my servers by FOUR minutes. I had originally set in group policy for the PDC emulator for my domain, a VM on one of my Hyper-V hosts, to get the time from the Public NTP hosts. I then configured a group policy to have all the other machines get their time from the PDC Emulator.
This was working great for me until I realized that my Hyper-V hosts were actually controlling the time of the VMs. They were also configured to get the time from the PDC Emulator, but essentially, due to how Hyper-V is configured, the PDC Emulator VM was getting the time from the Host. So, once the time got thrown off, everything went wacky on me!
I’d read through a couple of articles and found the configuration flaw of Hyper-V and the need for those servers to get their time from the external NTP hosts as well as be configured as NTP servers themselves. This totally went against my Group Policy configuration which caused the issue!
Luckily, I had a stand alone server that is a tertiary DC in the domain not running Hyper-V. I was able to get my time synced again properly after performing the following configuration.
I had to move the FSMO roles to the tertiary DC with the following cmdlet:
The one problem Hyper-V host that was syncing with the DC VM would not change settings via Group Policy nor through the w32tm cmdlet. I even went into the registry and tried to modify the following keys to make the changes stick:
The values would just not change, most likely due to the time not being synchronized. I had to reboot the server and then run through the process again in order for the changes to stick.
I did look at another article that said to do the following on the DC VM in order for time NOT to sync with the Hyper-V Host:
Go into Hyper-V console on the host machine, right-click on the client VM AD server, and select Settings. Once in here, on the left look under:
Management –> Integration Services Untick Time Synchronization Click Apply/OK
Things are running smoothly now. Please view the references at the bottom of the post. There are a couple of great articles about the Time Synchronization process with Hyper-V and why it needs to be setup the way I have it now. I wished I had read it before I originally set this up. I will post the article about getting group policy to handle the time sync process. Just remember, if your PDC Emulator is a VM, don’t sync it to a public NTP server. Sync it to your Hyper-V Host and have the Host sync publicly. In the long run, I think it is a good design solution to have your Hyper-V hosts time synced to the Public NTP servers than having to remember to configure each VM DC you create to NOT time sync with the host. To each is own though, and one thing I learned from working Microsoft, there are multiple ways to get to the same goal that are technically sound methods.
I was working on setting up a VM for my server farm and mis-configured one of the vhdx drives. I ended up having to delete that drive and recreate it in Hyper-V manager. When I did though, I received an error stating that I could not start the virtual machine:
An error occurred while attempting to start the selected virtual machine(s). ‘VMName’ failed to start. (Virtual machine ID ‘SomeID’) ‘VMName’ Microsoft Emulated IDE Controller (Instance ID ‘SomeID’): Failed to Power on with Error ‘General access denied error’ (0x80070005). (Virtual machine ID ‘SomeID’) ‘VMName’: IDE/ATAPI Account does not have sufficient privilege to open attachment ‘C:\Users\Public\Documents\Hyper-V\Virtual hard disks\DiskName.vhdx’. Error: ‘General access denied error’ (0x80070005). (Virtual machine ID ‘SomeID’) ‘VMName’: Account does not have sufficient privilege to open attachment ‘V:\Hyper-V\Virtual hard disks\DiskName.vhdx’. Error: ‘General access denied error’ (0x80070005). (Virtual machine ID ‘SomeID’)
Each virtual machine is started using a virtual machine account. The virtual machine account needs read and write access to the .vhd/.vhdx file, but if the file has just been copied from somewhere then it most likely lacks the necessary file permissions. That happened in my case because I had just created the vhdx drive and did not create it from the VM itself. I just attached it to the VM. So, when I booted the VM, it gave the error.
There are a few ways that you could remediate the issue. The simplest way, if it is a new VM, is to remove the drive in the VM settings and then re-create it from scratch. That is what fixed it for me. Another way is to add the VM GUID to the permissions so that it can access the vhdx file properly:
If you don’t already have the Hyper-V Manager error dialog open (“An error occurred while attempting to start the selected virtual machine(s) …”) then try to start the virtual machine now. You need the error open.
Click “See details”. This will show additional details, and will look something like:
‘PC-Name’ failed to start. (Virtual machine ID B9C4F7D4-0009-4BE2-90FB-9D60B1A06BDD) ‘PC-Name’ Microsoft Emulated IDE Controller (Instance ID XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX): Failed to Power on with Error ‘General access denied error’ (0x80070005). (Virtual machine ID B9C4F7D4-0009-4BE2-90FB-9D60B1A06BDD) ‘PC-Name’: IDE/ATAPI Account does not have sufficient privilege to open attachment ‘E:\Hyper-V\PC-Name\Virtual Hard Disks\MyVHD.vhdx’. Error: ‘General access denied error’ (0x80070005). (Virtual machine ID B9C4F7D4-0009-4BE2-90FB-9D60B1A06BDD) ‘PC-Name’: Hyper-V Virtual Machine Management service Account does not have sufficient privolege to open attachment ‘E:\Hyper-V\PC-Name\Virtual Hard Disks\MyVHD.vhdx’. Error: ‘General access denied error’ (0x80070005). (Virtual machine ID B9C4F7D4-0009-4BE2-90FB-9D60B1A06BDD) Where PC-Name will be the name of your virtual PC. The long sequence of letters and numbers (in my case above “B9C4F7D4-0009-4BE2-90FB-9D60B1A06BDD”) is the Virtual Machine ID. This number is significant and you need it to fix the problem.
On the host server open an elevated command prompt.
I have realized recently that I am an Exchange Messaging Professional, but yet, I have not posted the methodology of how I install an Exchange Server Mailbox Role. So here it is!
Install Windows Server 2019
Exchange Server 2019 requires Windows Server 2019 to run. For my environment, I haven’t necessarily need to follow all the enterprise level design aspects of database numbers to mailbox size ratios, number of servers, front/back end configurations, DAG Implementation, etc… If you want or need to delve into that realm, you can go here. I have need for a single server with only a few databases for a small number of mailboxes, so I am approaching it from that standpoint.
So first, in Hyper-V, I configured my VM with the following specifications:
Processors: 2 procs with 2 cores each – 4 Virtual Processors Total RAM: 32GB with dynamic memory enabled optional Drives: 2 .vhdx drives of 120GB each (OS / Exchange Data) CD: Windows 2019 ISO Default Settings for the rest of the VM Settings
Next I installed Windows Server 2019 Datacenter with the GUI! You can install it on Server Core if you wish. That information can be found in this link.
I ran through the setup of Windows and installed the OS on my first vhdx drive. I booted up, set the local admin password, and logged in. Once in Windows, I went to the Local Server Settings in Server Manager and configured the following settings:
Set the Date, Time, and Time Zone. (Once in the Domain, this would sync through Group Policy) Set IE ESC to allow Administrators to have full IE access. Set Remote Desktop Settings to gain RDP access. (This would be locked down with Group Policy as well once on the Domain) Set the IP Settings to Static Settings. (DNS Servers, Gateway, WINS, etc…) Join the server to the Active Directory Domain. Reboot the VM Server. Logon to your Domain. Configure Windows Update Settings. (I have WSUS through Group Policy, this was configured automatically upon reboot) Download and install all Windows Updates for the server. Then Reboot. Open Disk Management and configure the secondary vhdx drive to be your Exchange Data Drive. I configured the drive to be a mounted folder ‘C:\Exchange\Data’ rather than another drive letter as that seems to be the more accepted form of installation for the data drive these days. That is based on the multiple configurations that I have seen for Exchange through experience in Enterprise environments. Again, to each is own and depending on you design specifications, you might want to do that differently.
Next, we need to install the prerequisites for the Exchange Mailbox Server. I have always used practical365.com to get the PowerShell script to install the prerequisites, but couldn’t find the article this time. Great site though! Instead, I got the information and ran the following from an elevated PowerShell Session locally on the server:
PowerShell Exchange 2019 Mailbox Server Prerequisites
Once completed, you can begin the install of Exchange. If this is your first Exchange 2019 Server in your Organization, then you will need to run the following to update the Forest, Schema, and Domain so that Exchange will install properly:
PowerShell Exchange 2019 Setup Prepare Active Directory
PowerShell Exchange 2019 Setup Prepare The Schema
PowerShell Exchange 2019 Setup Prepare The Domain
NOTE: If you run into Prerequisite issues with the installation due to a “pending reboot”, check out my blog postfor information on remediation of that issue.
Now that the environment is prepared for Exchange, you can actually begin the installation. I wanted to make my default database and logs folder to be on the Exchange Data volume that I created, so I included those settings in the setup command. Please look at the reference to the setup.exe switches for more information on that. Here is the command:
PowerShell Exchange 2019 Setup Install The Mailbox Role
Setup should go through the installation via the PowerShell window and complete successfully. Reboot the Exchange Server, then you can then logon to the Exchange Admin Center and begin the process of configuration of how you need to integrate the Mailbox Server into your Server Farm. That configuration is for a later post.
Like most IT guys. They have a repository of their ISO images saved on a network share so that they can mount the ISO if needed on multiple machines. I recently switched to Hyper-V and have been having an issue with creating VMs and using my ISO from my network share to do so. Hyper-V Manager available through RSAT doesn’t have an option to mount an ISO or capture a drive from a machine on which is running. Instead it gives you drives of the Hyper-V host, and that would of course require you to have an ISO or the disc itself present on the host. I didn’t want to do that. I would rather have my repository share available for that purpose to allow for all the drive space to be available on the Hyper-V host.
So, I would map a network drive with my ISOs. The mapping would succeed, but mapped drive (letter) will not be visible in Hyper-V manager when trying to mount an ISO. Okay, so next I tried mounting from UNC share directly, but that would also fail, with the message: “‘VM’ failed to add device ‘Virtual CD/DVD Disk’” & “User account does not have permission required to open attachment”.
It goes back to the constrained delegation requirement for the Hyper-V host accounts to be used to perform functions such as this. This has been a pain to say in the least, as I have also had issues with live migration with my machines not being clustered due to different hardware.
So, in researching, I found this blog post. It has helped me through this issue with mapping the shared folder with the ISOs.
The cause of the problem is that the Hyper-V is intended to run with VMM Library Server and to mount files from it, not any random share. To re-mediate this:
You need to assign full NTFS and share permissions to computer account of Hyper-V on a shared folder with ISO’s you want to mount.
In AD on the computer account of Hyper-V machine delegate specific service ‘cifs’ to the machine you want your ISO’s mounted from. Microsoft calls this constrained delegation.
Here is step by step procedure for the constrained delegation:
Go to Active Directory Users and Computers
Find the Hyper-V server computer account and open up its properties.
Go to Delegation tab.
Select Trust this computer for delegation to the specified services only radio button.
Click the Add button.
Click the Users or Computers… button.
In the Add Services window, click Users or Computers and enter the computer account that will act as a library server and click OK.
Select the cifs Service Type and click OK.
The resulting setup should look something like this:
I added both the server that contained the ISO images and the server that I run my RSAT tools from just to be safe. I next rebooted the Hyper-V host (that is a requirement). When the host rebooted, I was able to successfully create the VM.
Hopefully, this will also solve my issue with live migration between my hosts. I will have to test that again and will inform everyone here if that succeeds as well!
As you may have knowledge of, if you are reading my blog. I am currently migrating off of VMWare to Hyper-V. Now, as I convert my machines to Hyper-V, it uses a totally different driver for the Network Card. I am having to rebuild the NIC settings within windows to setup the NIC for the Hyper-V VM to get the machines on the network properly again. The VMWare NIC disables and hides the NIC from the VMWare driver in Device Manager.
What this does is make Windows think it has two active network cards, even though one is disabled and removed/hidden in device manager. So, to clean things within Windows, I have to perform the following procedure to remove the hidden device:
Open PowerShell as Administrator Next, type the following cmdlet and press Enter:
Next, open Device Manager from the PowerShell Session:
When the Device Manager GUI opens, click the View menu Click Show Hidden Devices Go to the Device that is hidden, in my case the Network Adapter Right-Click the Device and select Uninstall Close the Device Manager GUI and PowerShell session
This cleaned the old hardware drivers off the system and allowed the current Hyper-V NIC to be the only one installed.
HAPPY TROUBLESHOOTING! PLEASE COMMENT!
Cookies Notice for itblog.ldlnet.net