Monitor's Get-Snapshot already tracks Phase 1-5 (Intune Registration,
Device Configuration, Software Deployment, Credentials, Lockdown).
The webapp dashboard only saw a single idx=7 push for the entire
post-PPKG / pre-lockdown window, so the friendly label couldn't
reflect "where is this bay actually". Operator looking at the
dashboard had no idea whether to assign category or hit ARTS for
lockdown next.
Monitor now pushes additional idx=7 entries as it crosses Phase
boundaries:
- On DeviceId capture: "Intune Device ID captured" (existing)
- On Phase 2 done (SFLD policy delivered = category was assigned):
"Phase 2 SFLD policy delivered (device configuration)"
- On Phase 1-4 all complete: "Phases 1-4 complete - ready for
lockdown (ARTS request)"
- On lockdown done: idx=8 (existing)
imaging.html maps the stage_string substring to friendly labels:
- default idx=7 -> "Registered - assign category"
- 'sfld policy' / 'phase 2' -> "Phase 2 - device configuration"
- 'credentials' / 'phase 4' -> "Phase 3 / 4 - DSC + credentials"
- 'ready for lockdown' / 'request lockdown' -> "Ready - request
lockdown" (hint: click ARTS request)
Operator now knows exactly when to act vs when to wait.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Was hiding LAPS QR section until idx=7 pushed with a DeviceId.
Operator couldn't paste a password if Monitor hadn't gotten around
to capturing the DeviceId yet. The QR encoding doesn't depend on
DeviceId - it's just the password being encoded - so the section is
useful any time the bay is past the LAPS reboot.
Drop the {% if s.intune_device_id %} gate. LAPS section now appears
in every expanded tile.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
localStorage-backed set of serials at key 'imaging-expanded'. On
DOMContentLoaded, walk each .imaging-card; if its data-serial is in
the set, set card.open=true. On every <details> toggle, update the
set. Refresh no longer collapses the tile the operator was looking
at.
Per-browser state (localStorage), no server round-trip.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Extended the data-filter attribute to include:
- friendly stage label (e.g. "awaiting intune lockdown")
- "stage-N" token (e.g. type "stage-7" to find idx=7 bays)
- status string (in_progress / succeeded / failed)
Use cases:
- Find all bays waiting on lockdown: type "lockdown"
- Find all bays at the same stage: "stage-7"
- Find failed bays: "failed"
- Find succeeded bays: "succeeded"
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Tile is now <details>. Always-visible summary:
- QR (96px)
- serial / hostname / pctype / machine# / status badge
- friendly stage label + N/M badge + pct
- progress bar
Click to expand. Body shows:
- friendly stage hint
- Intune device id row with [copy] [set category] [ARTS request]
- metadata one-liner (started / last / MAC / raw current_stage)
- error banner (if any)
- LAPS password QR generator
- log tail
- Clear button
ARTS button links to https://arts.dw.geaerospace.net/requests/type
for kicking off a new lockdown request (Intune-side step happens
externally; this is a deep-link for convenience).
Stage 7 wording: "Awaiting Intune lockdown" (was "awaiting category /
lockdown" - confusing when category was already assigned). Hint
explicitly mentions category check for cases where it isn't yet set.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Previously last_updated, MAC, started, Intune device id, and the
raw current_stage string were sprinkled around the card in
hard-to-track positions. Reorganized:
Row 1 (header): serial | hostname | pctype | machine# | status badge
Row 2 (stage): friendly label + N/M badge | pct% (right)
Row 3: full-width progress bar
Row 4: friendly hint (optional)
Row 5: Intune device id + copy + set-category (optional)
Row 6: started ... last ... MAC ... raw current_stage
Each row consistent across all cards regardless of which fields
are populated.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Tile shrunk for fleet density:
- QR: 160px -> 96px
- Drop big h4 for serial, use fs-6 strong instead
- DeviceId + buttons + MAC + started time consolidated into one
small grey row instead of three separate sections
- Progress bar 1.2rem -> 0.7rem
- mb-4 -> mb-2 between cards
- card-body py-2 for tighter vertical rhythm
Search:
- Sticky search input above the card list
- Filters live on serial, hostname, pctype, machinenumber,
intune_device_id via lowercase substring match on a data-filter
attribute
- Visible-count badge updates as you type ("3/12")
- Auto-refresh paused while query has text or while input is focused
Stage 7 label: was "assign category" only, now "awaiting category /
lockdown" to reflect that bays past category assignment are still
waiting on the Intune-driven LAPS-prompt reboot before lockdown.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Tile redesign:
- QR (or placeholder if not yet captured) on the left as a fixed 160px block
- Right side: header (serial / hostname / pctype / machinenumber / status)
then stage label as a big h4 with stage badge + % on the same row,
then full-width progress bar, then friendly stage hint
- Intune device id row with copy + set-category buttons consolidated
under the progress section
- Footer one-liner: started / last / MAC / raw current_stage (small grey)
- LAPS QR + log tail still expandable below
- shadow-sm for visual lift, no card-header line splitting
LAPS persist: POST password to /imaging/<serial>/laps so it survives
the dashboard refresh. Auto-renders QR on page load if the session
already has a stored password. Clear button POSTs empty string to
wipe server-side. No more 60s auto-clear - stays until cleared (or
daily server reset).
Refresh: 5s -> 15s. Reduces polling jitter + gives the eye time to
read before page flickers.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Was showing the raw push label (e.g. "Run-ShopfloorSetup: handoff to
Monitor-IntuneProgress") which only makes sense if you know the
playbook internals. Added a stage_index -> (label, hint) lookup table:
1 Booting from PXE WinPE loaded
2 Configuring Windows First boot baseline scripts
3 Installing apps 09-Setup-<pctype>
4 Apps installed preparing for enrollment
5 Enrolling in Intune PPKG + AAD/Intune join
6 Waiting on first Intune sync post-PPKG settle (~120s)
7 Registered - assign category idx=7 with QR + set-category btn
8 Imaging complete lockdown applied
Friendly label + one-line hint shown bold, raw stage string shown
underneath in small monospace for techs who want the playbook
breadcrumb. Stage index/total folded into a badge next to the
"Current stage" header so it doesn't need its own column.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
meta http-equiv=refresh fires every 5s and reloads the entire page,
wiping the LAPS QR state mid-scan. Replaced the meta tag with a
JS-driven setTimeout(location.reload, 5000) so renderLapsQR() can
clearTimeout it. Reload resumes when the QR is cleared (manual or
60s auto). Multi-bay safety: only resumes if no other bay still has
a QR rendered.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Per-bay <details> section with:
- Input field for LAPS password (paste from Intune portal manually,
since deep-link to LAPS blade needs AAD objectId we can't obtain)
- Make QR button generates a client-side QR from the input
- QR displayed below at 280px with 4-cell quiet zone
- Auto-clears input + QR after 60s with live countdown
- Manual Clear button
- Enter key on the input also triggers QR generation
Password never POSTs to server, never logged, never persists past the
60s window. Generated using the same qrcode-generator lib already
loaded for the device-id QR. Scan with a USB barcode scanner plugged
into the bay (HID keyboard mode) -> password types into bay login
field. Faster than reading off the Intune portal letter-by-letter.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
LAPS retrieval blade is keyed on AAD object id, not aadDeviceId /
mdmDeviceId. We capture aadDeviceId from dsregcmd; resolving to
objectId would require a Graph API call with Device.Read.All which
we don't have at WJ. Removed the LAPS button - operator goes to
Intune portal manually for LAPS as before.
set-category button stays - aadDeviceId works for that blade.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Two buttons next to the Intune device id on each bay card:
- "set category" -> portal.azure.us Intune device blade properties
via aadDeviceId/{deviceId}
- "LAPS" -> intune.microsoft.us encryptionKeys blade via
mdmDeviceId/{deviceId}
Both use the dsregcmd DeviceId we already capture - no Graph API
lookup or objectId resolution needed. One click from the dashboard
takes the tech to the right page for category assignment or LAPS
retrieval.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Single-site bay-stuck issue at WJ: GE Intune Report IP script filters
Get-NetIPAddress on StartsWith("10.") and posts everything matching
to the GE Tines webhook. Bays at WJ get the PXE LAN 10.9.100.x IP
captured and reported -> GE backend tags bays as on a non-corp 10.x
subnet -> dynamic group eligibility for SFLD policy never matches.
Other GE sites work because their PXE LANs aren't on 10.x at all.
Renumber PXE LAN to RFC1918 172.16.9.0/24 so the GE filter naturally
skips wired PXE addresses without any disable-NIC dance.
Server-side already in flight (netplan dual-bound, dnsmasq scope +
boot URL repointed, blancco preferences + grub.cfg + iPXE GetPxeScript
all sed'd to 172.16.9.1). This commit is the playbook / scripts /
docs side: 109 hits across 35 files sed'd in one shot.
After this lands + boot.wim is rebuilt + bays renumber off DHCP,
the 10.9.100.1 binding will be dropped from netplan as the final
cleanup step.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
navigator.clipboard.writeText is gated on isSecureContext - HTTPS
or localhost only. PXE dashboard is served over plain HTTP
(10.9.100.1:9009) so the API was undefined and the chain threw
before .catch fired - user saw nothing. Wrap clipboard write in
copyText() that prefers the modern API and falls back to the
classic invisible-textarea + document.execCommand('copy') path
which works on HTTP. Visual flash logic moved into flashCopied()
for reuse.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Click effect: button flashes green with "copied!" text and 1.15x
scale pulse, reverts after 1.2s. Failure case (clipboard API blocked
or HTTP context) shows red "failed" for 1.5s. Handler moved out of
inline onclick into a single delegated click listener at the doc
level so future copy buttons just need the .copy-btn class +
data-copy-text attribute.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Field bay surfaced two bugs in one diag dump (mdm-diag-F907T5X3 -
6PPSF24):
1. GE Proactive Remediation Report IP actually writes
GE_Report_IP_Address_2_5.LOG (uppercase .LOG), not the .txt I
assumed. Globs in two places had .txt filter -> never matched ->
Phase 1 stuck IN PROGRESS forever even after the file landed and
wired-NIC re-enable never fired. Drop extension from both globs
in Monitor-IntuneProgress.ps1 (id=7 push gate + p1Done check).
2. The "GE Re-enable Wired NICs" SYSTEM task registered by
Run-ShopfloorSetup was polling Autologon_Remediation.log for
"Autologon set for ShopFloor" - a lockdown-time signal. Re-enable
needs to fire at Report-IP time (well before lockdown) so that
Monitor can push idx=7 with the QR before the Intune-triggered
LAPS-prompt reboot. Repoint the SYSTEM task's poll to
C:\Logs\GE_Report_IP_Address* (any extension).
Plus minor UX: copy button next to the Intune device ID on
/imaging dashboard so techs can grab the GUID without having to
double-click-select the <code>.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Monitor-IntuneProgress.ps1: the previous Ensure-SendPxeStatus function
ran '. $lib' from inside the function body. PowerShell's dot-source-
inside-function semantics put the imported Send-PxeStatus into the
function's LOCAL scope, not the script scope. By the time Get-Phase1
called Get-Command Send-PxeStatus, the function had already returned
and Send-PxeStatus was out of scope - silently never invoked, no log
entry at all (success or failure). Diagnostic confirmed: bay had
DeviceId in dsregcmd, manual Send-PxeStatus from operator prompt
fired idx=7 cleanly with QR rendered, but Monitor's automatic call
never showed up in C:\Logs\send-pxe-status.log.
Fix: dot-source at script top-level (outside any function). Then
Send-PxeStatus is in script scope where every function in the file
can call it. Keep Ensure-SendPxeStatus as a no-op stub for any caller
still invoking it.
imaging.html: bump QR data-qr-size from 56 to 160 px. A 36-char UUID
at ECC M needs ~29x29 modules; at 56px each module was ~1.5px which
is too tight for a phone camera to lock onto from typical distance.
160 px gives ~5 px/module which scans cleanly.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Adds end-to-end progress tracking for PXE imaging sessions and surfaces
each Blancco report's BIOS serial in the report list.
webapp:
* services/imaging_status.py - JSON-per-serial state store under
IMAGING_DIR (default /var/log/pxe-imaging). Atomic write via
tempfile + rename. log_tail capped at 50 lines. Merges partial
updates so clients can post just the current_stage tick.
* config.py - new IMAGING_DIR env-overridable path.
* services/csrf.py - explicit exempt list for machine-to-machine
endpoints; /imaging/status is the first entry. Air-gapped LAN;
trust-by-network for client posts.
* app.py - four new routes:
GET /imaging dashboard (renders all sessions)
POST /imaging/status client status push (JSON body)
GET /imaging/<serial>.json raw session JSON for ad-hoc polling
POST /imaging/delete/<s> clear a session from the dashboard
Also parses each Blancco XML in the /reports list to surface
system.serial + system.model columns.
* templates/imaging.html - Bootstrap dashboard with per-session
cards (state badge, progress bar, stage idx/total, mac, elapsed,
log tail). meta http-equiv refresh=5 for auto-tick.
* templates/base.html - new "Imaging Progress" nav entry.
* templates/reports.html - Serial + Model columns added.
playbook:
* shopfloor-setup/Shopfloor/lib/Send-PxeStatus.ps1 - new helper.
Dot-source this then call Send-PxeStatus -Stage X -StageIndex N
-StageTotal M from any stage script. BIOS serial via CIM, MAC via
Get-NetAdapter, pctype + machinenumber from C:\Enrollment.
Failures are swallowed to a local log so a network blip doesn't
block imaging.
* shopfloor-setup/Run-ShopfloorSetup.ps1 - dot-sources helper +
posts at three coarse milestones (start, PPKG enrollment,
handoff to Monitor-IntuneProgress).
* shopfloor-setup/gea-shopfloor-keyence/09-Setup-Keyence.ps1 -
posts at session start + after Install-FromManifest with
succeeded/failed status derived from $rc. Other 09-Setup-*.ps1
scripts can follow the same pattern.
ID is BIOS serial (stable across WinPE -> Windows transition and
across reboots, unlike hostname which is random pre-PPKG). Operator
already knows the serial of the bay they imaged.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
