Here’s one that will fail deployments in environments that were working perfectly the day before the upgrade — and the cause is a config gap that was always technically there, just never enforced. From Configuration Manager 2509, WinPE is boundary-aware.
What changed
Previously, a device booted into WinPE could reach site systems without strict regard to boundary group membership. Now WinPE behaves like a full client: it resolves the management point it should talk to based on boundary group assignment. If the IP address the device picks up in WinPE doesn’t fall inside a boundary that’s tied to a boundary group with an assigned management point, the WinPE client can’t find an MP, and the task sequence fails early. You’ll see it in smsts.log:
Failed to query Management Point locator
Exiting TSMediaWizardControl :: GetPolicy
QueryMPLocator: no valid MP locations are receivedWhere it’ll actually bite
This surfaces in exactly the places people forget to configure: dedicated build/provisioning VLANs and PXE subnets that were never added to a boundary group. Imaging often happens on its own network segment, and if that segment isn’t represented in your boundary configuration with an assigned MP, OSD that worked fine yesterday stops working today. Refresh scenarios and bare-metal builds on those VLANs are the first to go.
What to do before you upgrade
Audit your OSD networks. Every subnet where devices PXE-boot or run a task sequence in WinPE needs to be in a boundary, that boundary needs to be in a boundary group, and that group needs at least one management point. Do it before 2509, not after the first failed image.
Source: Microsoft Learn. Summarised independently — check the source for the latest detail.