Files
pxe-server/scripts/diagnostics/snapshot-runbook.txt
cproudlock 1ae5bdce57 Add three-stage imaging snapshot tool + runbook
scripts/diagnostics/Capture-LockdownState.ps1 captures Windows endpoint
state at three lifecycle checkpoints so the deltas isolate which phase
delivered (or failed to deliver) each component:
  - pre-category   - PPKG-enrolled, no Intune category yet
  - post-category  - category-driven assignments arrived, pre-lockdown
  - post-lockdown  - kiosk + autologon + AppLocker fully landed

Bumped from the previous 2-stage (pre/post) version. Legacy 'pre'/'post'
aliases preserved.

Captures additions driven by the SFLD-DSC v2.0.2 post-mortem:
  - IMECache file listing (catches missing sastoken.txt)
  - DSCDeployment.log + version.txt copied from C:\pc\
  - SFLD\DSC payload listing
  - C:\Logs\BPRT\ runtime state (criticalChecks.json, packageInfo.json)
  - C:\WCDApps\ deploy verification
  - Windows\Provisioning\Diagnostics copy
  - Tasks-RunHistory.csv with LastRunTime + LastTaskResult per task
  - DeviceManagement-Events.csv (MDM 429s, AAD token failures)
  - Provisioning-Events.csv (PPKG runtime errors)
  - MDM-Certificates.csv (enrollment cert health)

scripts/diagnostics/snapshot-runbook.txt: step-by-step ops guide
covering when to fire each stage, where output lands, how to ship it
back via image-upload share, and which files to compare first when
diffing.
2026-05-01 08:53:52 -04:00

122 lines
4.8 KiB
Plaintext

SFLD imaging-lifecycle snapshot runbook
========================================
Run all three snapshots on the imaged device (elevated PowerShell). Each
captures registry, files, logs, scheduled-task state, and event logs at a
distinct lifecycle checkpoint so the deltas between them isolate which
phase delivered (or failed to deliver) each component.
Prereq: device is in supportuser auto-logon, just finished PPKG bulk
enrollment, and is enrolled to Intune but no device category assigned yet.
----------------------------------------
0. Map share + stage script (run once, at the start)
----------------------------------------
net use Z: \\10.9.100.1\image-upload /user:pxe-upload pxe /persistent:no
Copy-Item Z:\Capture-LockdownState.ps1 C:\Windows\Temp\
Set-ExecutionPolicy -Scope Process Bypass -Force
----------------------------------------
1. Snapshot BEFORE assigning device category
----------------------------------------
State:
- PPKG ran, enrolled to Intune
- Device sitting in SupportUser, no category assigned in portal yet
- Win32Apps + DSC profiles tied to category have NOT delivered
C:\Windows\Temp\Capture-LockdownState.ps1 -Stage pre-category
Output: C:\ProgramData\state-pre-category-<stamp>\
----------------------------------------
2. Assign device category in Intune portal
----------------------------------------
- Intune portal -> Devices -> Windows -> [this device] -> Properties
- Set Device category to MAIN (or whichever is correct)
- Wait ~5-10 min for sync (or force sync via Settings -> Accounts ->
Access work or school -> Info -> Sync)
----------------------------------------
3. Snapshot AFTER category, BEFORE lockdown
----------------------------------------
State:
- Category lands, dynamic-group membership evaluates
- SFLD-DSC Win32App (or whatever the category-driven config is) has had
a chance to download, install, write registry, schedule its task
- Lockdown has NOT yet flipped Winlogon DefaultUserName from SupportUser
to ShopFloor (i.e., still in tech / setup mode)
C:\Windows\Temp\Capture-LockdownState.ps1 -Stage post-category
Output: C:\ProgramData\state-post-category-<stamp>\
----------------------------------------
4. Wait for lockdown to finish landing
----------------------------------------
Watch for the two terminal signals (per Monitor-IntuneProgress.ps1
notes):
- HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
DefaultUserName flips from "SupportUser" to "ShopFloor"
- AssignedAccess kiosk profile becomes active
----------------------------------------
5. Snapshot AFTER lockdown
----------------------------------------
C:\Windows\Temp\Capture-LockdownState.ps1 -Stage post-lockdown
Output: C:\ProgramData\state-post-lockdown-<stamp>\
----------------------------------------
6. Copy all three snapshots back to PXE
----------------------------------------
Get-ChildItem 'C:\ProgramData\state-*' -Directory |
Where-Object Name -match '^state-(pre-category|post-category|post-lockdown)-' |
ForEach-Object {
robocopy $_.FullName "Z:\$($_.Name)" /E /NFL /NDL /NJH /NJS
}
net use Z: /delete /y
The three folders land at \\10.9.100.1\image-upload\state-*-<stamp>\.
On the workstation: pull from /home/pxe/image-upload/ on the PXE server
(scp or local mount) and diff against any prior baseline (e.g. the
4/15 v1.3.1 working snapshot at pxe-images/state-post-lockdown-20260415-154705/).
----------------------------------------
What each diff reveals
----------------------------------------
pre-category -> post-category
- Which Win32Apps Intune assigned via the category
- Whether SFLD-DSC bootstrap actually ran (DSCDeployment.log,
HKLM:\SOFTWARE\GE\SFLD\Credentials\baseVersion)
- Whether sastoken.txt was present in the IMECache (IMECache-Files.csv)
- Scheduled task SFLD-ApplyDSCConfig - was it created? Did it run?
What was its last result code? (Tasks-RunHistory.csv)
- Outbound MDM events: 429 throttles, AAD failures
(DeviceManagement-Events.csv)
post-category -> post-lockdown
- Lockdown DSC delta: AssignedAccess kiosk config, AppLocker rules,
Winlogon flip, autologon change
- Final registry state for HKLM:\SOFTWARE\GE\SFLD\Credentials\* +
HKLM:\SOFTWARE\GE\SFLD\DSC (Site, Environment, Function, SasToken)
- Final PolicyManager state (which Intune profiles fully landed)
----------------------------------------
Key files to look at first when comparing
----------------------------------------
SFLD.reg -> creds + DSC values landed?
IMECache-Files.csv -> sastoken.txt present in Win32App content?
DSCDeployment.log -> bootstrap version + warnings
Tasks-RunHistory.csv -> SFLD-ApplyDSCConfig LastRunTime + LastTaskResult
DeviceManagement-Events.csv -> 429s, AAD token failures, sync stalls
GE-WOW6432.reg -> baseVersion (1.3.1 = working, 2.0.2 = broken)