Last week I ran into an issue with SCVMM and Bare metal deploying Hyper-V hosts. During testing I was deploying several HP blades with the same Physical Computer Profile. But some hosts had the Hyper-V Server 2012 R2 OS, which was the one I configured in the Physical Computer Profile and others had the Windows Server 2012 R2 OS.
After recreating the .vhdx file the problem seemed to be gone, but it returned. During the deployment of de host in the WinPE mode I pressed Shift+F10 to open a command prompt and opened the VMMAgentPE.exe.log file to view any error’s. There I discovered it was downloading the wrong VHDX file.
———————–
0518.0654::07/14-10:21:26.793#09:OSDActionMiniProvider.cpp(804)[00000000026AA7: CFileInformation::
DownloadFileFromUrl HttpServerName: cna2.nl.xxx.local, HttpServerPort: 443, HttpResource:/e87f01571c95cf5245182f32063cc6965ae95af2/Y:A5cSharesA5cSCVMMLibrary
A5cDataA5cOSImagesA5cWindowsServer2012R2Standard.vhdx/Y:A5cSharesA5cSCVMMLibrary
A5cDataA5cOSImagesA5cWindowsServer2012R2Standard.vhdx/, FileSizeBytes: 8338276352, UseSSL:
-1, TargetFilePath: E:\WindowsServer2012R2Standard.vhdx
———————–
My Physical Computer profile had different vhdx file.
A social technet dissussion lead me to the vhdx Family and Operating system settings. In this environment I had the same issue. 2 vhdx files with the same Family and Operating system names.
After changing the Hyper-V server vhdx to a different Family Name and Operating System the deployment of the HP Blades was stable with Hyper-V 2012 R2, but I still don’t know why SCVMM just pics a disk based on Family name and Operatingsystem tags when I explicitly provide a vhdx to use in the Physical Computer Profile. I know Azure Pack leans on the tags but apparently the Bare Metal Deployment process does to.
Good luck deploying!