SCCM only deploys one PXE image. The one associated with the last Task Sequence 
you Deployed.

This gets interesting, but can be fixed quite easily.

Deploy or re deploy a Task Sequence that uses an X64 Boot Image, and SCCM will 
“switch” to using that image within a few minutes.

We are currently in the same boat (UEFI forces x64 boot images, while we need 
x86 boot images to deploy x86 versions of Win7 for legacy stuff). I ended up 
making PXE x64 only, and provide techs an ISO of the x86 media for the legacy 
stuff.

Jason Lang

From: [email protected] [mailto:[email protected]] On 
Behalf Of Andrew Berges
Sent: Thursday, July 17, 2014 10:42 AM
To: SMS Mailing List
Subject: [mssms] OSD & PXE Weirdness

Greetings All,
I recently completed an upgrade to Configuration Manager 2012 R2 CU1 and now 
want to begin building images for Windows 8.1 deployment.  I have created the 
task sequences for 32 and 64-bit platforms and had previously used the task 
sequences to successfully generate two Windows 8.1 images within VM's.
I've now made some tweaks to the task sequence and want to run them again, but 
I'm having trouble with PXE always providing the incorrect architecture to the 
64-bit task sequence.

I'm using a series of Hyper-V VM's, some Generation 2 (for 64-bit builds), some 
Generation 1 (for 32-bit builds, since UEFI implementation on Hyper-V doesn't 
allow 32-bit).

I have numerous "build" task sequences deployed to a test collection and all my 
VM's are a member of this collection.  However, when I look at the SMSPXE.log, 
the VM's are only seeing one deployment ID, the 32-bit 8.1 build sequence (and 
associated 32-bit boot image).
Both boot image platforms are deployed to the PXE server, and when I boot a 
Generation 1 VM, PXE boot clearly shows "Architecture: x64", yet it's still 
being passed the 32-bit boot image.
What am I missing here?  If there are a series of task sequences targeted to a 
system with both 32 and 64-bit boot images, how does SCCM/WDS determine which 
one to pass to the client?
Thanks in advance,

Andrew


Reply via email to