Operating System Deployment is often equated with bare-metal imaging — a new laptop rolls off the shelf, PXE-boots into WinPE, receives a Windows image, and lands on the user's desk fully configured. That scenario still exists, but in practice it has become the smallest of the four categories that OSD in Configuration Manager actually addresses. In-place upgrades from Windows 10 to Windows 11, feature-update deployments between annual Windows 11 releases, and hardware-replacement migrations with user-state preservation together make up the bulk of modern OSD work.
The following article approaches Operating System Deployment as a platform, not as a single scenario. It describes the building blocks that every OSD scenario draws from, walks through the four deployment paths that cover virtually all real-world needs, and closes with a structured troubleshooting section anchored in the task sequence log.
The lab from Building an SCCM Lab on Windows Server 2025 provides the environment: LAB-CM01 as the primary site and distribution point, and LAB-CL01 as the test target. The Windows ADK for Windows 11 24H2, installed as part of the lab preparation, delivers the WinPE runtime on which all of OSD relies.
The Four OSD Scenarios
Before any configuration is touched, it is worth grounding the terminology. Microsoft divides OSD scenarios along two axes: whether the existing OS survives, and whether the target hardware changes.
Bare Metal A new or wiped machine with no operating system. The task sequence boots WinPE (through PXE, bootable media, or a prestaged image), partitions the disk, applies an OS image, and layers drivers, applications, and settings. This is the scenario closest to classic deployment images.
Refresh An existing machine keeps its hardware identity but receives a fresh OS. User data and settings are captured before the wipe (typically through the User State Migration Tool, USMT), the system is reimaged, and the captured state is restored. Useful for major OS rebuilds when the hardware stays.
Replace An old machine is decommissioned, a new machine takes its place, and user data moves from one to the other. The task sequence on the old system performs a state capture to a share or to the State Migration Point, and a separate task sequence on the new system restores it after installation.
In-Place Upgrade The existing OS remains — its major version or feature update is raised, applications and settings are preserved, and no reimage occurs. For Windows 10 → Windows 11 and for Windows 11 feature updates (24H2, 25H2, …) this is the dominant path in enterprise environments. The mechanics differ fundamentally from the three imaging scenarios: there is no WinPE phase, no disk repartition, no USMT.
The four scenarios share the same underlying components but combine them differently. Learning OSD means learning the components first, then recognising which combination a given situation requires.
OSD Building Blocks
Boot Images
A boot image is a boot.wim that contains a customised WinPE environment. Configuration Manager uses it as the runtime for the imaging phases of a task sequence. Two default boot images — one x64, one x86 for legacy scenarios — are created automatically when OSD is first used, drawing on the WinPE add-on installed with the Windows ADK.
Boot images are managed under Software Library → Operating Systems → Boot Images. Two operations matter in practice:
- Update Distribution Points — applies the latest drivers, optional components, and ConfigMgr binaries to the boot image, then redistributes it. Necessary after any ADK upgrade and after any change to the boot image properties.
- Distribute Content — ensures the boot image is available on every DP that needs to serve it, including those used for PXE.
For custom hardware support, network or storage drivers can be injected into the boot image through Properties → Drivers → Add. The selected drivers must be WinPE-compatible; not every production Windows driver is.
# List boot images
Get-CMBootImage | Select-Object Name, PackageID, Version | Format-Table -AutoSize
# Trigger a boot image update from PowerShell
Update-CMDistributionPoint -BootImageId "LAB00001"Operating System Images vs Operating System Upgrade Packages
ConfigMgr distinguishes two artifacts that carry Windows bits:
Operating System Image
A .wim file extracted from Windows installation media (sources\install.wim), typically placed on a file share and imported into the console. Used by imaging scenarios — Bare Metal, Refresh, Replace. The task sequence calls Apply Operating System to write the image to the prepared partition.
Operating System Upgrade Package
The full contents of the Windows ISO (the extracted sources folder and everything around it). Used by In-Place Upgrade scenarios. The task sequence calls Upgrade Operating System, which internally runs setup.exe from the package with arguments that preserve applications and user data.
The two artifact types are not interchangeable. A frequent source of confusion is selecting an OS Image when an OS Upgrade Package is needed. Creating both for the same Windows release is fine and, for mixed estates, often necessary.
Both are created under Software Library → Operating Systems → Operating System Images or Operating System Upgrade Packages. Distribution to DPs follows the same content distribution pattern as any other package.
Driver Packages
Drivers can be handled in two ways. The classic approach is the Driver Package — a collection of extracted driver sets associated with a specific hardware model (Dell Latitude 7450, Lenovo ThinkPad X1 Gen 12, etc.). The task sequence selects the correct package based on a condition, typically a WMI query against Win32_ComputerSystem.Model.
WMI namespace: root\cimv2
WQL query: SELECT * FROM Win32_ComputerSystem WHERE Model LIKE "%Latitude 7450%"The alternative is Auto Apply Drivers, a task sequence step that scans the staging catalog during deployment and injects matching drivers automatically. It is simpler but less predictable; most production environments prefer model-specific driver packages for reproducibility.
For In-Place Upgrades, drivers are generally left untouched — the existing Windows installation keeps its driver stack across the upgrade.
Task Sequences
A task sequence is the orchestration script of OSD. It is a sequence of steps — imaging, partitioning, configuration, application installation — executed top to bottom with support for conditions, grouping, and error handling. ConfigMgr provides templates for the common scenarios:
- Install an existing image package — Bare Metal + Refresh
- Upgrade an operating system from an upgrade package — In-Place Upgrade
- Build and capture a reference operating system image — legacy, rarely used with modern Windows servicing
- Custom task sequence — an empty shell for bespoke flows (non-OS workflows)
The templates are starting points. In production, they are almost always modified — variables added, applications inserted, post-image configuration scripts included.
A Basic OS-Install Task Sequence
The fastest path to a working OSD environment is to build the Install an existing image package task sequence against an imported Windows 11 24H2 image. This covers the Bare Metal scenario and, with one additional step, the Refresh scenario.
Prerequisites in Place
Before the wizard runs, the following must exist and be distributed to LAB-CM01:
- Boot Image — the default
Boot image (x64)is sufficient for a first pass - Operating System Image — Windows 11 24H2, imported from
install.wim - Client Package — the Configuration Manager Client Package, created automatically
- USMT Package — the User State Migration Tool for Windows package, needed for Refresh
- Optionally: Driver Packages and Application references
All packages must be distributed to the DP before the task sequence deployment is created. A common early mistake is missing content on the DP, which causes the task sequence to fail at the Download Package Content phase with a content hash error.
Running the Template
Under Software Library → Operating Systems → Task Sequences, Create Task Sequence launches the wizard. The relevant choices for a Windows 11 24H2 install:
- Type — Install an existing image package
- Boot image — Boot image (x64)
- Image package — Windows 11 24H2 (imported earlier)
- Partition and format — standard UEFI layout (required for Windows 11; Secure Boot compatible)
- Join a domain —
cm.lab, using a dedicated Domain Join account (in the lab, a domain admin) - Install the Configuration Manager client — yes, with the site-specific properties (
SMSSITECODE=LAB SMSMP=LAB-CM01.cm.lab) - State migration — disabled for Bare Metal, enabled for Refresh with a USMT package
- Install applications — selected ConfigMgr Applications will run after the OS is fully configured
The wizard produces a multi-step task sequence with sensible defaults. The result is editable — the Edit action opens the full step tree, where conditions, variables, and additional steps can be inserted.
Task Sequence Structure
A typical install task sequence looks like this when flattened:
Install Operating System
├── Restart in Windows PE
├── Partition Disk 0 - UEFI
├── Apply Operating System
├── Apply Windows Settings (timezone, locale)
├── Apply Network Settings (domain join)
└── Apply Device Drivers (optional; auto apply or package-based)
Setup Operating System
├── Setup Windows and ConfigMgr
└── Restart Computer (to the new OS)
Install Applications
└── Install Application (one or more ConfigMgr apps)
Post-OS Configuration
└── Custom scripts, registry tweaks, agent installationsEach step has properties, conditions, and an Options tab controlling continue-on-error behaviour. Good practice is to group related steps so that conditions apply at the group level rather than being repeated per step.
The In-Place Upgrade Task Sequence
In-Place Upgrade follows a different template — Upgrade an operating system from an upgrade package — and produces a much shorter sequence. There is no WinPE phase, no partitioning, no USMT. Windows Setup runs within the existing OS and preserves applications and user state.
Prepare for Upgrade
├── Check Readiness (built-in hardware/OS readiness check)
└── Cleanup Disk (optional Disk Cleanup)
Upgrade the Operating System
└── Upgrade Operating System (calls setup.exe from the OS Upgrade Package)
Post-Processing
├── Restart Computer
├── Run Setup Diagnostics (optional, for failure analysis)
└── Custom post-upgrade tasksTwo practical considerations apply to every In-Place Upgrade task sequence:
- The compatibility scan is non-optional. Windows Setup's own compatibility check runs unconditionally and can block the upgrade. The Check Readiness step in the task sequence is a pre-flight that fails fast when obvious blockers exist (insufficient disk, incompatible hardware, BitLocker suspended incorrectly).
- BitLocker handling. An encrypted drive requires a suspension before the upgrade and a re-protection afterwards. The template includes the basic pattern; production deployments often extend it with backup of the recovery key to AD or Azure AD.
Documentation: In-place upgrade with Configuration Manager.
Deploying a Task Sequence
A created task sequence does not execute until it is deployed. Deploy is launched from the task sequence's context menu and configures three fundamental aspects.
Collection Targeting
A task sequence is deployed to a device collection. Two collection patterns dominate:
- Explicit membership — a staging collection with hand-picked devices, typical for pilot and controlled rollouts
- Query-based membership — a collection whose members are computed from a WQL query against discovery data, for example all workstations in OU X not on Windows 11 24H2
Collections for OSD must include the Unknown Computers collection when Bare Metal PXE deployments are intended — unknown systems that PXE-boot have no device record and rely on this special collection to receive any deployment at all.
Purpose: Available vs Required
- Available — the task sequence appears in Software Center; the user chooses when to run it
- Required — the task sequence runs automatically at the configured deadline, with or without user interaction
Available deployments give users control and are the default for optional upgrades. Required deployments drive compliance campaigns. For In-Place Upgrades, a common pattern is a long available window with an eventual required deadline that enforces compliance after a grace period.
Make Available to Boot Media and PXE
For Bare Metal scenarios, the deployment must be made available to Configuration Manager clients, media and PXE (or the PXE-only variant). Without this setting, the task sequence cannot be selected in WinPE during a PXE boot.
Distributing the Content
Before deployment, every package referenced by the task sequence — boot image, OS image or upgrade package, client package, USMT, driver packages, applications — must be on at least one DP reachable from the target's boundary group. Missing content surfaces as Failed to download policy or The referenced package could not be found in the task sequence log.
Triggering a Task Sequence
Three delivery paths cover the realistic scenarios:
PXE Boot
The target is powered on into the network boot sequence; the DP's PXE service answers with boot.wim. WinPE loads, contacts the MP, enumerates available task sequences for Unknown Computers (or for a known record), and the user selects one. PXE requires the Enable PXE support for clients option on the DP and a reachable DHCP infrastructure that either offers the DP directly through DHCP options or relies on DHCP/PXE helper proxying.
Bootable Media A USB stick or ISO with the boot image and the task sequence policy. Ideal when PXE is not available or not desired — remote sites, one-off installs, air-gapped labs. Created through Task Sequences → Create Task Sequence Media in the console.
Software Center (In-Place Upgrade and Refresh) For task sequences that run inside a booted OS — In-Place Upgrade above all — the ConfigMgr client pulls the policy, stages the content, and either runs the task sequence immediately (Required deployment) or offers it in Software Center (Available deployment). This is the dominant path for modern OSD work.
Standalone Media A fully self-contained deployment medium (USB or ISO) that includes the OS image, boot image, and all referenced packages. No network connection to ConfigMgr is needed during the deployment. Heavy on size but useful for field work and disconnected scenarios.
Troubleshooting OSD
OSD troubleshooting is different from application deployment troubleshooting: much of the action happens inside WinPE, where no normal client is running, and the logs live on a RAM drive that disappears at every phase change. Knowing where the logs go at each point is the primary OSD skill.
The smsts.log Hierarchy
smsts.log is the central task sequence log. Its location changes throughout the deployment:
- WinPE phase, before disk is ready:
X:\Windows\Temp\SMSTSLog\smsts.log - WinPE phase, after disk is partitioned:
C:\_SMSTaskSequence\Logs\smsts.log - Full OS phase, during task sequence execution:
C:\_SMSTaskSequence\Logs\smsts.log - After task sequence completes (success):
C:\Windows\CCM\Logs\smsts.log - After task sequence fails:
C:\Windows\CCM\Logs\smsts.logplusC:\SMSTSLog\in some configurations
The _SMSTaskSequence folder is deleted at the end of a successful deployment but remains after a failure, which makes post-mortem analysis possible.
Interactive Debugging in WinPE
During WinPE, pressing F8 opens a command prompt — but only if Enable command support (testing only) is enabled on the boot image. In the lab this is on by default; in production it is typically disabled for security. From the WinPE command prompt:
# Find the current smsts.log
dir /s /b x:\smsts.log
dir /s /b c:\smsts.log
# Inspect network state
ipconfig /all
ping LAB-CM01.cm.lab
# Check disk state
diskpart
> list disk
> list volumeA common trick is to tail smsts.log in WinPE with CMTrace, which can be copied to the boot image as an Optional Component or made available through a scripted step.
Deployment Monitoring
The console provides a live view under Monitoring → Deployments →
Common Error Codes
The task sequence engine returns a 32-bit error code. A handful account for most real-world failures:
- 0x80070002 — file not found; typically a package that failed to download
- 0x80004005 — generic WMI or provider failure; often permission-related during Apply Operating System
- 0x80070570 — corrupt file; boot image or OS image hash mismatch, solved by re-distributing content
- 0x80072EE7 — name resolution failure; DNS or network stack problem during the MP contact
- 0x87D00326 — content download failed; the task sequence could not pull a package from any reachable DP
- 0x80091007 — hash validation failed; usually a sign that content on the DP is corrupted and must be redistributed
Common Pitfalls
Task sequence never appears on PXE boot Most common cause: the deployment is not made available to media and PXE, or the target is not a member of a collection with a matching deployment. Cross-check via Monitoring → PXE and confirm the DP received the PXE-enabled request.
BIOS-to-UEFI transition fails silently Windows 11 requires UEFI and Secure Boot. A device that arrived in BIOS/Legacy mode will install successfully but never reach a booted OS. Task sequences must include a Set Dynamic Variables step or a firmware transition step (e.g., the MBR2GPT-based pattern) before partitioning.
Drivers load in WinPE but not in the full OS (or vice versa) WinPE driver injection and full-OS driver injection use different packages. Network drivers in particular must be in the boot image for WinPE connectivity, while storage controllers for the final OS must be in the driver package applied during Apply Device Drivers.
The machine rolls back after an In-Place Upgrade
Windows Setup rolled back due to a compatibility issue. The primary source is C:\$WINDOWS.~BT\Sources\Panther\setupact.log on the client, plus setuperr.log in the same folder. Looking only at smsts.log will point at the task sequence step without revealing why Setup rolled back.
Applications fail to install at the end of the task sequence The task sequence engine runs in System context and installs applications through the ConfigMgr client. Applications that require a user context will not install at this point. For user-specific configuration, a separate Available deployment or an Intune / ConfigMgr policy applied after first logon is the right path.
Content is stuck on the DP as "In Progress"
A package update that never completes is usually a corrupt PkgSource or a permission issue on the content library. The distmgr.log on the site server reveals the underlying error. Redistributing from scratch (Distribute Content → Remove from all DPs, then re-add) usually resolves it.
Domain join loop on new images If the image was sysprepped improperly, or if the domain join account does not have permission to create computer accounts in the target OU, the task sequence may complete in WinPE but fail at first boot during the Apply Network Settings or at the domain join. Verifying the account's Create Computer Objects right on the target OU is the first check.
Takeaways
OSD in Configuration Manager is broader than the bare-metal scenarios it is often reduced to. The four deployment paths — Bare Metal, Refresh, Replace, In-Place Upgrade — share the same building blocks but combine them differently, and recognising which combination applies to a given operational need is the central skill.
In practice, the In-Place Upgrade scenario dominates modern OSD work. Its mechanics are unlike imaging — no WinPE, no partitioning, no USMT — but the same task sequence engine orchestrates it, and the same content distribution, collection targeting, and deployment semantics apply.
Troubleshooting OSD is a discipline of its own, anchored in smsts.log. The log's location shifts with the phase of the deployment, and finding it at the right moment — especially during WinPE, where no conventional client is running — is half the battle.
Rule of thumb: Build a task sequence one step at a time, distribute content before deploying, verify in a lab against a throwaway VM, and read smsts.log first when anything misbehaves. The complexity of OSD comes from its breadth; the individual pieces are, taken separately, straightforward.
Tested with: Configuration Manager Current Branch 2503 on Windows Server 2025, Windows ADK 11 24H2, Windows 11 24H2 as the deployed OS, Hyper-V Gen2 VMs with UEFI and Secure Boot.