SCCM 2012 R2 PXE with 64-Bit UEFI

[Clamb]

I have to apologize for the length of the post right up front.

 

I am having an issue with PXE boot while using SCCM 2012 R2. The issue is only with 64-Bit machines using UEFI. All others are working correctly.

 

This is running in a test lab so it's a pretty simple setup at this time. I have two boot images (x86 and x64), both are distributed to the DP's and Unknown Computer support is enabled.

 

I have two Task Sequences that I am testing. One is a Windows 7 x86 sequence - using the x86 Boot Image.The other is a Windows 8.1 sequence - using the x64 Boot Image. No applications or anything special in the task sequence, just standard OS installation.

 

I was initially deploying both the x86 and x64 task sequences to the "All Unknown Computers" group. However, this caused issues as SCCM was selecting the initial PXE boot image based upon the last deployment. Therefore it would not always boot the correct architecture. I know I can boot the x86 image and deploy a 64 Bit OS. However, UEFI breaks all of this. When you attempt to PXE boot in UEFI mode, the architecture of the boot image must match the architecture of the machine.

 

I have a mixture of x86 (Latitude 10 tablets) as well as newer x64 UEFI machines. There are also both x86 and x64 non UEFI capable machines. So I need to be able to support Non-UEFI as well as UEFI PXE booting for both the x86 and x64 architectures.

 

To get around the issue with publishing multiple task sequences to Unknown computers, I have created two Collections to try to separate the x86 Unknown Computers and x64 computers. The collections each contain 1 member, the "x64 Unknown Computer" and "x86 Unknown Computer", respectively. I then modified the Windows 7 x86 task sequence to deploy to the "Unknown x86 Computers" collection. I also modified the Windows 8.1 task sequence to use the "Unknown x64 Computers" collection.

 

I can now successfully boot an x86 NON-UEFI machine, an x64 NON-UEFI machine, as well as a UEFI x86 machine. They all pick up the correct boot image and run the task sequence just fine.

 

The issue I am having is specifically with the UEFI 64-Bit machines. They PXE boot just fine, however when they do, they boot from the x86 Boot Image. Of course this doesn't work because of the UEFI mode. I get the following error:

 

 

I have attached the SMSPXE.log file in case this helps.

 

Now, here is the interesting part.....

 

If I import the UEFI 64 Bit test machine via either the MAC address or GUID and add this to a collection and then deploy the Windows 8.1 Task Sequence to this collection, the machine boots the correct x64 Boot Image and runs the task sequence just fine.

 

Anyone have any ideas how I can specifically target UEFI 64-Bit machines through a collection?

 

-Chris

SMSPXE.log

[Frederc Puente]

Hello Clamb,

 

Can't bring you a solid answer but try to read this article explaining differences between UEFI and BIOS boot through PXE:

 

http://henkhoogendoorn.blogspot.fr/2014/03/pxe-boot-files-in-remoteinstall-folder.html

 

Regards,

[anyweb]

try re-deploying whatever task sequence it is to a collection, the last task sequence deployed will contain the boot wim that all successive task sequences on that collection will use for first boot (and then they'll stage their respective boot wim)

[Lucero]

Hi Nail,

 

I am in the same boat as the OP (and currently have to keep deploying a task sequence to unknown comps based on what machine I'm building).

 

I can't quite grasp your response. Could you explain a little further what you mean to do?

 

Thanks

[Mikey C]

I have experienced this. Basically, the device which is running EFI mode PXE will not boot from that 32-bit boot media.

 

You cannot specify directly, which boot media a device will use (whether 32 or 64 bit), but when you deploy a task sequence, the boot image associated with it becomes the chosen one' that client machines will PXE boot from.

 

So re-deploying a 64-bit task sequence might solve the problem for you, but we have some devices (Lenovo Tablet 2 devices, they are crap) which will only boot in EFI mode and only from 32-bit media, they cannot revert to BIOS mode, and they cannot run 64-bit code.

 

So, this means that we cannot PXE boot 64-bit devices, we can only boot them using USB flash drives.

 

If anyone has a better workaround, or knows why the 32-bit boot media causes the "Windows Failed to Start" message above on 64-bit devices, please let us know!!

[kweathe]

I am not sure if everyone has a solid answer yet but I have working with this issue for a while. I will highlight below.

 

You can direct boot images x86 and x64 through the use of Collections and Targeted Boot Image on the Task Sequence. With that said unknown computer support has been THE issue. CLAMB is right to separate the Unknown x86 and Unknown x64. However, once you do that you can NEVER use the combined All Unknown Collections again. UEFI has to match architecture. Traditional Bios or UEFI in legacy can use the X86 for both x86 and x64. This is not an SCCM problem or a PXE problem but a UEFI architecture change.

 

When the machine sends a request SCCM through PXE, SCCM determines what to present based on if it's known or unknown. If it is known then it presents based on what collections the device MAC is associated with. If it is unknown and unknown computer support is enable then SCCM will present those options. Because the All Unknown Collection has both architecture types in the collection SCCM will present the boot image on the last known deployment type. Many of us attribute this as an SCCM problem. And granted MS could have done a better job by not lumping the two together but this is a fairly new issue and UEFI is still young.

 

This is what I have done to solve the issue and it seems to be working as expected. I no longer have to swap around Task Sequences because of the SCCM last Deployment rule. Tablets and UEFI have made some interesting changes in the way we construct Collections and Target Deployment. I see this issue everywhere I go and there have not been any good articles that walk through it.

 

I hope this helps someone.

http://247sccm.com/sccm-2012-r2-pxe-with-uefi/

[anyweb]

to add to the above and to explain further think of it like this

 

UEFI devices must boot from a boot image architecture which matches the architecture of the device, so if the UEFI device is 64bit, then the boot image that answers first (lifo rule) must be 64bit otherwise you'll get an error during network boot,

 

this is not a problem if you don't have different architecture hardware, for example if your entire estate is 64bit, then use a 64bit boot wim attached to your task sequence,

 

infact that is what we do where I work, we are using a 64bit boot wim as the LAST task sequence deployed to our deploy collection, this works for all operating systems we are deploying except where the architecture of the os requires an x86 boot wim, and for those devices we stage the boot wim (as they are legacy)

 

unfortunately with UEFI you can't stage so the first boot wim that answers must match the architecture of the UEFI device or it will fail, this is ok if all your UEFI devices are 64bit, but that's not always the case, in the case where they are 32bit, either image them differently (usb media for example) or setup a collection infrastructure that allows only 32bit UEFI devices to boot with a 32bit boot image ....

 

to complicate matters even further, traditionally people have been deploying both 64bit and 32bit operating systems in ConifMgr using a 32bit boot wim, this no longer works with the UEFI mix as described above, so if you want to cover most UEFI and Legacy hardware, move to 64bit boot wims and deal with the 32bit hardware and 32bit operating systems as exceptions.

 

i.e. a 32bit boot image can deploy both a 32bit and 64bit operating system (legacy) however a 64bit boot wim can only deploy a 64bit operating system...

[Clamb]

Since I started the original topic the issue I was having was resolved with CU3. I can now boot 64bit machines and get the correct architecture. I still have to separate the x86 and x64 collections and I can't advertise to Unknown Computers. However I assumed that would be the case which is how this whole thread started in the first place. Up until CU3 even with the separate collections, and 64bit UEFI machine was identifying itself as an x86 platform first. Now it identifies itself as an x64 bit system. This makes it select the 64 bit boot image. This is exactly the functionality I was trying to get.

 

The unfortunate downside is any unknown machine can't be re imaged until it runs collection tasks which add it to another Collection I have advertised the task sequence to. This happens from time to time when we have a system fail during imaging. Our solution, for now, is to just delete the machine record and therefore make it unknown again.

 

-Chris

[Rocket Man]

You could import the computers information via MAC address to overcome this and add it to a collection that has the correct deployed TS architecture boot file added. This way if it fails you can just clear the PXE flag and boot again without deleting the computer object. Has PROs and CONs, Cons is it can be slow to gather this info and import, PROs is that if you are imaging in MASS you wont have to wait until all other systems are successfully imaged before you can associate and delete the unknown objects with the failed deployments.

[kweathe]

Chris you bring up another good point. One way to speed things up is modify when certain collections update membership. I always check Incremental and set the imaging collection to update every hour when we are doing a bulk run. You can also manually run a membership update. It's not instant but close enough in most cases. And like Rocket Man suggest you can delete the object, you are reimaging anyway. One note, clearing the PXE flag only works for required deployments. That is not an option for available since you are always presented with the deployment choices that are deployed as available to that collection group.

[ksurgener]

I like the workaround provided by kweathe with having a unknown computers collection for both architecture types, however, in my environment, I have consolidated the majority of our task sequences into a single task sequence. The problem this creates is pretty obvious; you can only assign a single boot image to a task sequence. The only option, I suppose, is to duplicate the task sequence and very carefully maintain them so that they remain identical except where they must differ. Oy vey.