Boot image selection during PXE in System Center 2012 Configuration Manager (ConfigMgr) is something that comes up from time to time in the forums as well as every-day discussions. This can be quite confusing to explain or comprehend in normal language even though it’s truly not that difficult once you get it.
The logic for boot image selection is actually contained in relatively small stored procedure named NBS_GetPXEBootAction and (mostly) copied at the bottom of this post for reference. Here’s a concise summary of this stored procedure (although a few minor nuances are left out):
- Find all task sequence deployments targeted at the system being PXE booted (lines 36-44)
- Filter out the following:
- Task Sequence deployments for task sequences with no boot images (lines 43-44).
- Task Sequence deployments with boot images not on the DP being PXE booted from (lines 47-48)
- Required Task Sequence deployments that have run on the target system before (line 55)
- Order the Task Sequence deployments by
- Required or available (required first)
- OfferID (highest first)
The boot image associated with the task sequence deployment ordered first by this stored procedure is then sent to the client. And there you have the boot image selection process for ConfigMgr.
- This stored procedure doesn’t look up a device in the database to determine if it’s known or unknown, that’s handled by two other stored procedures called before this one: NBS_LookupDevice and MP_GetClientIDFromSmbiosID.
- Architecture of the PXE booted system or boot image is not accounted for so make sure you are properly targeting your task sequences to consider boot image architecture and UEFI.
- OfferID is synonymous with the DeploymentID of the task sequence and more recent deployments have higher IDs.
- OfferID ordering orders by task sequence deployment creation time and not task sequence creation time. Thus, more recently deployed task sequences are ordered before task sequences deployed in the past.
- If only one task sequence is applicable to a device, of course there’s only one possible boot image based upon the above. The only time the stored procedure is truly significant is if there is more than one task sequence targeted at a system. This creates possible ambiguity which is then effectively resolved by this stored procedure.
- To manipulate boot image selection, create a new task sequence deployment targeted at the system(s) where you need to change what boot image is used. This will create a deployment with a larger DeploymentID which will be ordered at the top of the list by the stored procedure.
The process described here isn’t about which boot image a task sequence will actually use; that is always dictated by the boot image assigned to the task sequence. This process is about which boot image will be delivered to a PXE booted client at PXE time. This may differ from the boot image ultimately used because ConfigMgr may not know which task sequence will actually be executed as this isn’t always set at PXE time. Basically, anytime there is more than one possible task sequence deployed to a system, ConfigMgr does not know which task sequence is going to be run so has to make a choice about which boot image to deliver for PXE boot purposes. After the task sequence is determined (usually based on user input and well after the PXE boot has happened), if the boot image associated with that task sequence is different from the one used to boot, then ConfigMgr will pre-stage that boot image to the system and reboot to it.