SCCM Task Sequence Troubleshooting: Reading smsts.log Like a Pro
smsts.log locations per phase, TS variable debugging, failure code dissection and driver injection fixes — read ConfigMgr task sequences like a pro.
C
CloudEngineerHub Team
Published: September 13, 2026· Last Updated: September 28, 2026·9 min read
SCCM Task Sequence Troubleshooting: Reading smsts.log Like a Pro
It is 21:40. The morning shift expects 60 reimaged laptops, and the task sequence dies at "Setup Windows and ConfigMgr" on every machine in batch three. The difference between an engineer who goes home and one who sleeps under the desk is not knowledge of task sequences — it is the ability to open the right log, in the right phase, and find the first error instead of the fortieth echo of it. smsts.log is not a mystery; it is a diary that moves around the disk as the deployment progresses. Learn where it lives per phase and how it writes, and task sequence troubleshooting becomes lookup, not archaeology.
Visual Walkthrough
C
CloudEngineerHub Team
Author
The CloudEngineerHub editorial team — Microsoft endpoint management and cloud engineers writing hands-on guides on Intune, Azure, Entra ID, Autopilot, Defender and PowerShell. Every article is reviewed against current Microsoft documentation.
Final health checks; 0x80070002 usually = content, not fate.
Task Sequence — smsts.log Checkpoints. 1. Boot image loads: WinPE starts; smsts.log in X:\windows\temp. — 2. Disk partitioned: UEFI/BIOS aware partitioning; disk logs included. — 3. OS image applied: WIM applied + drivers injected; log moves into OS. — 4. Unattend + domain join: Setup completes; join fails show here first. — 5. Apps & ts variables: Install-application steps honor dynamic variables. — 6. Success gates: Final health checks; 0x80070002 usually = content, not fate.
Prerequisites
ConfigMgr current branch console access with read rights to the target collection and deployments.
Access to site server logs (<InstallPath>\Logs) and DP logs (SMS_DP$\sms\logs share) for content- and PXE-side checks.
Boot images with command support (F8) enabled for live debugging in WinPE.
CMTrace (ships with the client and boot images) or OneTrace from Support Center — never Notepad; smsts.log without highlighting is a haystack.
A USB boot media or PXE-enabled DP, depending on your deployment entry point.
Where smsts.log Lives in Each Phase
The single most common troubleshooting delay is looking at yesterday's log — the one from the previous phase. The log file itself moves as the OS context changes:
Moves to C:\Windows\CCM\Logs\smsts.log after the TS completes
New OS, post-Apply-Image phase
C:\_SMSTaskSequence\Logs\Smstslog\smsts.log
The famous "vanishing log" location before the client agent exists
WinPE — TS engine startup failures
X:\smstslog\ plus SMSTS*.log companions
Also check TSManager.log and TSAgent.log siblings
Live-session pro tips
Pro tip for live sessions: in WinPE with F8 enabled, cmtrace X:\smstslog\smsts.log and leave it open — CMTrace auto-scrolls and highlights errors. When the log "disappears," the path changed; check both candidates before assuming anything failed.
How to Read It: First Error Wins
smsts.log lines follow the standard ConfigMgr log format: date, time, component, context (thread), type, then text. Type codes matter: LOG_ERROR lines are what you hunt; the same error is typically followed by dozens of consequence lines. The discipline:
Search for Failed / failed with error / The task sequence execution engine failed — then walk upward to the first failure, not downward.
Note the HRESULT beside the failure — it is your search key for the knowledge base and for this article's table below.
Note the step name in the surrounding context; the error's location in the sequence often narrows the cause faster than the code itself.
Check _SMSTSLastActionSucceeded references — a FALSE there tells you exactly which step died when you compare timestamps.
Sweep a captured log for its first failures like this:
PowerShell
1
2
3
$log = "C:\_SMSTaskSequence\Logs\Smstslog\smsts.log"
Select-String -Path$log -Pattern"Failed to run the action|failed with error|0x8" |
Select-Object -First15 | ForEach-Object { $_.Line.Substring(0, [Math]::Min(220, $_.Line.Length)) }
Field note: The most misread line in smsts.log is the one right before a wall of retries. Engineers fix the retry symptom (a timeout) while the real failure two lines up is a missing driver or a full disk. Always identify the first !-grade failure in the timeline, not the loudest.
Task Sequence Variables: Debug the Environment, Not Just the Steps
Half of task sequence breakage is a variable problem in disguise: a wrong package ID, a stale collection variable, an empty condition, a domain-join value from last year's lab. During a live TS (with F8), dump the whole environment to a file and read it like a config dump:
PowerShell
1
2
3
4
# Run inside a running task sequence (WinPE with F8 or full OS step) to dump variables$tsenv = New-Object -ComObject Microsoft.SMS.TSEnvironment
$out = foreach ($vin$tsenv.GetVariables()) { "{0} = {1}" -f$v, $tsenv.Value($v) }
$out | Out-File -FilePath"$($tsenv.Value('_SMSTSLogPath'))\ts-vars.txt" -Force
Variables you will reach for constantly: _SMSTSLogPath (where logs land right now), _SMSTSMachineName, _SMSTSRunFromDP-related content flags, OSDImageIndex/ImagePackageID (Apply OS inputs), and any custom variable you filter conditions on. Collection and machine variables show up in the dump exactly as the engine sees them — which ends "it should be set" debates instantly.
The Failure Codes That Matter
Memorize the short list; it covers the overwhelming majority of real incidents:
Code
Meaning
First thing to check
0x80070002
File not found
Content/package reference wrong, or step pointing at a missing file
0x80070005
Access denied
Network Access Account / DP share permissions, package distribution
0x80070035
Network path not found
DP unreachable from subnet, NIC driver missing in WinPE
0x80070070
Disk full
Disk size vs image size; stale partitions; USB boot media quirks
0x8007000E
Out of memory
Boot image too fat (driver bloat), low-RAM device
0x80091007
Hash mismatch
Content corrupted on DP — refresh distribution
0x80190194 / 0x80190190
HTTP 404/400 from IIS
MP/DP web tier — virtual app misconfig, cert bindings
0x80004005
Unspecified failure
Read surrounding lines; usually a step-specific root cause above it
Two war stories
Two of these deserve war stories. 0x80070002 in the Apply OS step usually means the image package ID referenced by the TS no longer exists on the DP (retired content, orphaned reference) — check the step's package ID against Monitoring > Distribution Status before touching anything else. 0x80091007 is almost always a DP content corruption, not a client problem — refresh the package on the DP and move on; checking hash-on-client settings to "work around" it just moves the failure.
Driver Injection: The Classic Money Pit
"Unknown device" in Device Manager after a perfectly green task sequence is a driver problem, and the log tells you which kind:
Boot image drivers (network + storage) belong in the boot image; missing NIC drivers manifest as 0x80070035 in WinPE because the machine cannot reach the DP at all. Missing storage drivers manifest as "no disks found" — the Apply OS step has nothing to apply to.
Operating system drivers are injected at the Apply Driver Package step or auto-applied from driver packages. When injection fails, smsts.log carries the DISM error and dism.log (in the offline image context) carries the reason — typically an INF that does not match the OS build or a driver package exported from the wrong model.
Model-specific logic: Two reliable patterns — separate driver packages per model applied via a WMI condition on SELECT * FROM Win32_ComputerSystem WHERE Model LIKE ..., or MDT-integrated total-control logging via ZTIDrivers.wsf. Both beat "dump every driver in one package" by a mile.
Field note: If a new hardware model fails driver injection, test the INF set manually with pnputil or DISM against a mounted image before blaming the task sequence. Nine times out of ten the vendor's "Windows 11 driver pack" contains an OS-generation mismatch that no TS step can rescue.
Visual Walkthrough
The professional investigation loop every troubleshooting post assumes.
Client log, service-side report, or event channel — one at a time.
filter
2
Filter to the window
Timestamps first: start where the failure actually happened.
correlate
3
Correlate across layers
Client ↔ service ↔ event logs agree on the same story?
hypothesis
4
Form one hypothesis
State it falsifiably: "detection ran before install finished".
verify
5
Verify in clean test
Reproduce in a pilot device with logs open — then generalize.
6
Document the fix
Runbook entry: symptom → root cause → durable fix.
Log Triage Method — Collect, Filter, Correlate, Conclude. 1. Collect the right source: Client log, service-side report, or event channel — one at a time. — 2. Filter to the window: Timestamps first: start where the failure actually happened. — 3. Correlate across layers: Client ↔ service ↔ event logs agree on the same story? — 4. Form one hypothesis: State it falsifiably: "detection ran before install finished". — 5. Verify in clean test: Reproduce in a pilot device with logs open — then generalize. — 6. Document the fix: Runbook entry: symptom → root cause → durable fix.
PXE vs Boot Media: Different Doors, Different Logs
The entry point determines where your first logs live:
PXE boot: The DP-side SMSPXE.log (in SMS_DP$\sms\logs) decides whether the device gets a boot file at all. Classic errors: PXE-E53: No boot filename received (device not known and unknown-computer support disabled), TFTP timeouts (network + PXE responder tuning territory — see Microsoft Learn's PXE responder configuration guidance), and "no task sequences advertised" (deployment not targeted to the unknown-computer objects or collection the device fell into).
Boot media: Skips PXE entirely; failures here are usually media-stale (old boot image), USB controller drivers missing from the boot image, or boot image architecture mismatch (x64 image on a device that needs x64 UEFI handling configured).
Deployment type: Available vs Required changes behavior dramatically — PXE-required deployments will re-run and wipe on accident if left attached. When a machine PXE-boots and immediately starts a TS "by itself," check for lingering required deployments to All Unknown Computers; that is a data-loss incident waiting for a user.
Deep captures
For deep captures, enable F8 and pull the whole log set at once:
CMD
1
2
:: In WinPE: copy the current TS logs to a USB stick (E:)
xcopy /c /i /y X:\smstslog\*.log E:\ts-logs\
Log Splitting and Long Runs
smsts.log rotates when it reaches its size cap; the rolled file keeps a timestamp suffix (e.g., smsts-20260214-034210.log). On long deployments (multiple reboots, large images) the current log may hold only the last minutes — the diagnosis you need sits in the rolled file. Open the newest rolled file plus the live one in CMTrace, merge by timestamp, and read the timeline across the reboot boundaries. Support Center's OneTrace does the merging for you and tolerates larger files; keep both in your toolkit.
Key takeaways
smsts.log moves with the phase: WinPE (X:\windows\temp\smstslog or X:\smstslog), post-format (C:\_SMSTaskSequence\Logs\Smstslog), full OS (C:\Windows\CCM\Logs\smstslog) — checking the wrong path wastes the first 20 minutes of every incident.
Read errors top-down in time: find the first failure and its HRESULT; everything after is consequence, not cause.
Dump task sequence variables with the Microsoft.SMS.TSEnvironment COM object during a live run to end condition and variable debates with evidence.
0x80070002/0x80070005 are content and permission failures; 0x80091007 is DP content corruption (refresh, don't re-run); 0x80190194 is IIS-side.
Boot image needs NIC + storage drivers; OS drivers belong to driver packages applied per model — verify with Win32_PnPEntity error codes after OSD.
PXE failures start in SMSPXE.log on the DP; boot-media failures are usually stale media or missing controller drivers.
smsts.log rotates on size — for long deployments, include rolled files in the timeline and prefer OneTrace for merged reading.
Frequently asked questions
The log keeps disappearing mid-deployment — where did it go?
The engine moves the log between phases and drive letters (WinPE X: to the formatted disk). Check X:\smstslog, then C:\_SMSTaskSequence\Logs\Smstslog, then C:\Windows\CCM\Logs\smstslog in order; the file did not vanish, the context did.
Can I run a task sequence interactively to debug step by step?
Not natively — task sequences are automation, not interactive sessions. The supported debugging pattern is F8 in WinPE, variable dumps via the TS environment COM object, and liberal use of Pause-style script steps (a cmd /c pause step or a PowerShell step with Read-Host) in your lab image only.
What is the fastest fix for 0x80070002 during Apply Operating System?
Validate the image package still exists on the target DP and the TS step references the right package/image index — the error is almost always a content reference problem, not disk state. Confirm via Distribution Status, refresh if needed, and verify the DP's content library before retrying the client.
Comments
0No comments yet — be the first to share your thoughts.