He was trying to build a new x64 generation 2 virtual machine using ConfigMgr 2012 R2 but it was failing with the following error:
File: \Windows\System32\boot\Winload.efi
Status: 0xc0000359
We noticed that upon hitting F12 to boot the machine was pulling down the x86 boot image. At this point the machine was unknown to ConfigMgr, and our unknown computers collection had 2 task sequences advertised - Windows 8.1 x64 and x86
So we disabled the x86 task sequence and voila! it booted from the x64 wim, We then re-enabled it and it booted from the x86 wim.
Not happy with this behaviour I dug a little deeper......
SMSPXE.log told us the deploymentID it had selected ended in 20017 and this gave me an idea, we turned to Deployments under the Monitoring workspace in the ConfigMgr console and viewed the DeploymentIDs of our 2 task sequences.
We noticed that the x86 one ended in 20017 and the x64 ended in 20016, it seemed that the newer DeploymentID of the two was taking precedence....
So we deleted the x64 deployment and recreated it, which then gave it a higher DeploymentID than the x86 task sequence (below)We tried it again and it pulled down the x64 wim file this time! Result!
To be sure this was the cause we then did the same with the x86 task sequence (deleted and re-deployed it) and sure enough it pulled down the x86 wim file.
So long story short: Deploy your x64 task sequence last if you are deploying more than one task sequence to a collection
Cheers
Wayne
Thank you Thank you Thank you!
ReplyDelete