ConfigMgr 0xc0000359 error code on Generation 2 UEFI machine

I came across a strange issue today whilst working with a colleague I met on a project.

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

Replace failed disk in Areca raidset

A quick post on how to replace a failed disk in an Areca raidset:

Replace the faulty disk in the server, power up and launch the web admin console. Once open and logged in expand RaidSet Functions | Create Hot Spare

Set the new disk as a hot spare and you should see "Rebuilding" in the web console :)

 

Wayne