Install-FromManifest.ps1:
- Get-CurrentMachineNumber reads the eDNC/DNC registry FIRST (reassignment-
authoritative), falling back to C:\Enrollment\machine-number.txt. The txt is
written once at imaging and is NOT updated on reassignment, so txt-first
gated reassigned bays on a stale number.
- Per-entry try/catch in the app loop: a single entry that throws no longer
aborts the whole scope (skipping every later entry + the status write). It is
logged, counted failed, and the loop continues. This was silently killing the
collections scope at the MTConnect Makino entry, which also stopped the
ShopDB asset reporter (a later entry) from ever running.
Deploy-ShopfloorStartLayout.ps1 (new): local-DSC port of the Intune
desktop-weblinks + Start-menu pins (copies .url/.lnk to Public Desktop +
All-Users Start Menu, writes the ConfigureStartPins JSON policy, resets
start2.bin + restarts the shell). Verified on Win11: pins render after logon.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Adds Report-AssetToShopDB.ps1 (Type=PS1, DetectionMethod=Always manifest entry)
for collections PCs. Reads hostname, BIOS serial, eDNC MachineNo and the corp
NIC IPv4 (filtered to WJ corp ranges, controller NIC dropped) and POSTs
action=updateCompleteAsset to ShopDB api.asp, which upserts the machine, stores
the IP, and links the PC to its machine-number equipment. manifest-entry-report-asset.json
is the snippet to merge into the SFLD share collections manifest (+ stage the
script under apps/). Note: relies on the ShopDB api.asp LogToFile Err-leak fix
(separate shopdb repo commit) to create the relationship reliably.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
PartMarker was missing from the PCType alias map, so gea-shopfloor-partmarker
matched no alias set and common manifest entries gated by PCTypes (notably
Oracle Client 11.2) were pc-filtered out - Part Marker PCs never installed
Oracle. Adds @('PartMarker','gea-shopfloor-partmarker') to the alias groups.
The companion fix (adding partmarker+heattreat to Oracle's PCTypes list) lives
in the SFLD share common/manifest.json. Verified on the win11 VM: with PCType
gea-shopfloor-partmarker the Oracle entry is now evaluated (0 pc-filtered).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
WinPE maps the enrollment share early, then idles for minutes while the WIM
applies. deadtime=5 dropped that idle session, so the post-apply staging
copies failed (bay left with only site-config.json staged). VM test against
the live share copied everything fine on a fresh mount; the only difference
was the idle. deadtime=0 disables idle auto-disconnect. Applied live to the
current box (smbd reloaded); this makes it permanent + covers the second box
on the next playbook run.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
WinPE maps Y: early then idles for minutes during the WIM apply; samba
deadtime drops the idle session, so the WinPE staging copies failed (bay
left with only site-config.json). Add Fetch-StagingPayload.ps1, run from the
unattend FirstLogonCommands at first logon on a FRESH share mount (full
Windows, no prior idle), to pull the shopfloor-setup tree + preinstall
bundle. Detailed per-item log (exit code, counts, timing, mount retries) at
C:\Logs\Fetch\ - the old WinPE staging was opaque.
- Fetch runs as Order 4, BEFORE wait-for-internet.ps1 (Order 5) which switches
the bay to the production network and off the imaging LAN. So Fetch still
reaches \172.16.9.1\enrollment.
- WinPE bulk staging kept as best-effort fail-fast fallback (Phase 1); the
post-boot Fetch is now the authoritative path. Remove the WinPE bulk once
validated. Heavy per-type payloads (CMM/Keyence/WaxTrace) stay in WinPE for
now - Phase 2.
- startnet stages Fetch-StagingPayload.ps1 + writes fetch-source.txt
(UNC/user/pass) for the post-boot mount.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
A Display bay staged only site-config.json then nothing - winpe-staging.log
ended at 'Copied site-config.json'. PCTYPE/PPKG were both set, so it was not
a menu bug: execution froze at the very next step, the PPKG copy
copy /Y Y:\ppkgs\... W:\Enrollment\...
A bare 'copy' from a network drive has no timeout; when the Y: SMB handle
stalled it blocked forever, so pc-type.txt / shopfloor-setup / preinstall
never ran (Display kiosk + Common OpenText both depend on the preinstall
phase). Convert every bare 'copy /Y' in the staging path to
'robocopy /R:1 /W:1' (fail-fast retry, no overwrite/dir prompts). robocopy
exit codes are inverse of copy (0-7 ok, 8+ fail) so the PPKG check flips to
errorlevel 8, and since robocopy keeps the source name the PPKG gets a ren
to its BPRT-tagged target. A stalled share now fails one step and continues
instead of freezing the whole stage.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Neither new PC type had a pcProfile, so they fell back to the top-level
defaults, which deliberately exclude eDNC. Result: no DNC desktop shortcut
or taskbar pin on either type. Add profiles mirroring gea-shopfloor-
nocollections (eDNC + NTLARS baseline) plus the type-specific apps:
- gea-shopfloor-partmarker: Mark (C:\Program Files (x86)\Mark\bin\Mark.exe)
+ Telesis Backup400/420/470 (C:\Program Files (x86)\Telesis\Backup4xx\).
- gea-shopfloor-heattreat: HeatTreat
(C:\Program Files (x86)\HeatTreat\bin\HeatTreat.exe).
Deployed to the live enrollment share (config/ + shopfloor-setup/).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- 09-Setup-CMM.ps1: Step 2.5 ACL list targeted C:\Program Files\DODA (a path
that never exists), so the BUILTIN\Users write grant on DODA was silently
skipped. Corrected to C:\Apps\DODA, where Install-DODA.ps1 actually extracts.
- Install-DODA.ps1: create C:\Apps\DODA\PreProcess after extract. The DODA
zip unpacks flat without it; MergeFiles.exe expects it and crashed with
DirectoryNotFoundException (MergeFiles.GetDoDAFolder) when absent.
- docs/cyberark-cmm-doda-policy.md: EPM admin reference for elevating the CMM
report toolchain. CyberArk EPM elevation is per-process and not inherited, so
the external tools PC-DMIS spawns (MergeFiles/PCDToIGES/RotateProbeVector/
DovetailAnalysis) run un-elevated and fail. Doc gives the Application Group
(by SHA-256), the Elevate policy, scope, verify steps, and the
CREATE_PDF_FROM_RTF.BAS rework that drops Word/Reader from the elevation set.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Install-FormtracepakSettings decided per-user vs HKLM by matching the
filename against 'HKEY_USERS'. The backup names files after their source
path, so an operator pref captured from HKCU:\ lands in a file named
"HKCU_..." with content root HKEY_CURRENT_USER - which the filename match
missed entirely, dropping it from the restore.
Read each .reg once and classify by its content root(s):
[HKEY_CURRENT_USER... -> per-user, remap root to HKEY_USERS\<targetSid>
[HKEY_USERS\<srcSid>... -> per-user, remap srcSid -> targetSid
[HKEY_LOCAL_MACHINE... -> HKLM
The temp rewrite (UTF-16-LE for reg.exe import) is only written when the
content actually changes; otherwise the file imports as-is.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
A capture from a working CMM4 bay showed the goCMM registry holds two
distinct values under HKLM\SOFTWARE\WOW6432Node\General Electric\goCMM:
Shared Data Directory = C:\geaofi\ (constant on every bay)
Selected Part Group = \\tsgwp00525...\SHARED\... (the per-bay UNC path)
The prior commit (f6d970c) put the per-bay path into "Shared Data Directory",
which is wrong. Correct that:
- bay-config column shared_data_dir -> part_group
- resolve-cmm-bay-config emits partgroup.txt (was shareddatadir.txt)
- 09-Setup-CMM seeds "Shared Data Directory" to the constant C:\geaofi\ and
"Selected Part Group" to the per-bay path, converting the friendly S:\...
form to the \\tsgwp00525.wjs.geaerospace.net\SHARED UNC at apply time.
Users write grant on the key is unchanged.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
HeatTreat bays pick a machine number (6601-6604) at imaging; 02-Setup-
HeatTreat now imports the matching reg\<machine-number>.reg after the MSI,
rewritten to WOW6432Node (DNC is 32-bit; reg import does not honor /reg:32),
mirroring the Part Marker WJPRT.reg flow.
- startnet.cmd: route gea-shopfloor-heattreat to the machine-number prompt
(was defaulting to skip), so machine-number.txt is written for the picker.
- The 6601-6604 .reg files are gitignored (they carry a DNC FtpPasswd
credential) and deploy via the enrollment share from the working tree.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
goCMM (.NET x86) stores its program-source path in HKLM\SOFTWARE\
WOW6432Node\General Electric\goCMM value 'Shared Data Directory'. Being
HKLM, a non-admin shopfloor user cannot set it via goCMM's UI (nor save a
Selected Part Group switch). 09-Setup-CMM Step 2.7 now seeds the per-bay
path (admin context at imaging) and grants BUILTIN\Users write on the key,
mirroring the existing Step 2.5 install-dir ACL grant.
- cmm-bay-config.csv: add shared_data_dir column (per-bay paths, CMM1-12).
- resolve-cmm-bay-config.ps1: write C:\Enrollment\cmm\shareddatadir.txt
(space-safe; e.g. CMM8 'Venture CMM8').
- 09-Setup-CMM.ps1: Step 2.7 reg seed + Users ACL on the goCMM key.
Not yet deployed to the live server (held).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
New gea-shopfloor-partmarker type (startnet menu option 10) and fill the
gea-shopfloor-heattreat stub. Both follow the collections eDNC pattern:
01-eDNC.ps1 installs DNC, then a 02-Setup script installs the vendor MSI.
Part Marker (02-Setup-PartMarker.ps1):
- msiexec Mark-6.2.1.msi /qn /norestart LAUNCHNTLARS=false (the LaunchNtlars
custom action otherwise fires under /qn and launches NTLARS mid-install,
same as eDNC).
- After install: import WJPRT.reg rewritten to WOW6432Node (reg import does
not honor /reg:32; DNC is 32-bit and reads the redirected hive), then copy
the Mark overlay + eMxInfo.txt into C:\Program Files (x86)\Mark.
HeatTreat (02-Setup-HeatTreat.ps1):
- msiexec HeatTreat_6.2.1.msi /qn /norestart LAUNCHNTLARS=false. Existing
09-Setup-Heattreat.ps1 (OpenText) still runs after. Optional .reg/file
copy left as a marked TODO pending confirmation.
Both MSIs decompiled: WiX/GE Aviation, no forced reboot, only LaunchCondition
is NOT NEWERVERSIONDETECTED. utilpassword.txt is gitignored (secret, deployed
via the enrollment share from the working tree).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Oracle Client 11.2 is 32-bit. On 64-bit Windows the registry key lives
under WOW6432Node but the preinstall detection was reading the native
64-bit path, which doesn't exist. Detection always failed, causing a
redundant reinstall on every re-image. The GE-Enforce manifest had the
correct path since 2026-05-01 but preinstall.json was missed.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The .NET cal Setup.exe crashes (0xE0434352) on 218-378-13 series ISOs
even when filenames are clean (no trailing-space bug). Previously only
bypassed when the ' _' trailing-space signature was detected. Now
detects by probe series ID in the data filenames too and always does
direct file copy for 218-378-13.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The variable was renamed to $backupDirCandidates + $bd loop but the
else-branch log message still referenced the old $backupDir, producing
a malformed path like "\.zip" in the log.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Every copy/robocopy during the W: staging phase now appends to
W:\Enrollment\winpe-staging.log (persists as C:\Enrollment\ post-boot).
robocopy gets /LOG+ to append its file list; echo lines log timestamps
for each stage. Helps diagnose missing-file issues post-imaging.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The picker was reading unit_serial and probe_part from the old INDEX.csv
format. bay-config.csv uses different column names (ftpak_version, model,
host). Updated Select-Object and display format to match.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Add bay picker (same arrow-key pattern as waxtrace) that maps CMM1-12
to a PC-DMIS version (2016/2019/2026) and DODA flag via cmm-bay-config.csv.
startnet.cmd: replace Standard/DODA submenu with bay picker. Writes
CMMID (e.g. CMM4) to machine-number.txt so the existing
TargetMachineNumbers filter on the SFLD share manifest gates per-bay
entries with no lib changes.
09-Setup-CMM: reads resolved version.txt and filters cmm-manifest.json
by _CmmVersion tag at imaging time so only the matched PC-DMIS version
installs.
cmm-manifest.json: add PC-DMIS 2026.1 entry (patched MSI, product code
{81BACE1B-FB08-4DCF-8100-79911AD3EC1E}) and DODA entry (flat zip extract
to C:\Apps\DODA\). Existing 2016/2019 entries tagged with _CmmVersion.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
09-Setup-CMM: add Step 2.6 that launches each installed PC-DMIS
version once as admin before the PPKG locks the machine down. Also
adds PC-DMIS 2026.1 to the ACL directory list.
Controller credential: cmdkey /add under SYSTEM stored creds in the
wrong vault. Switch to a Register script (MarkerFile detection, runs
once) that creates an AtLogOn scheduled task under BUILTIN\Users so
cmdkey runs in the ShopFloor user's session.
IE compat: update test matrix hash for the new site list that adds
wjfms3.apps.wlm.geaerospace.net.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Waxtrace staging already used robocopy (8e1f81b, f95d305) but the
shopfloor-setup baseline, common, _ntlars-backups, type-specific,
pre-install, CMM, and Keyence copies still used xcopy with zero error
visibility. Switch them all to robocopy /E /MT:16 /R:1 /W:1 with
errorlevel-8 warnings so copy failures surface on the WinPE console.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
- gea-shopfloor-nocollections/02-MachineNumberACLs.ps1: gut to no-op
matching the collections variant. SYSTEM Apply task no longer needs
per-user ACLs on the eDNC reg key or UDC ProgramData dir.
- Configure-PC.ps1 item 6 (Machine number logon prompt toggle):
Stop duplicating Register-ScheduledTask logic inline. Call the
shared Register-CheckMachineNumberTask.ps1 registrar so both the
Prompt user-task and Apply SYSTEM-task are installed with matching
SDDL config. Existence check now treats EITHER the new "Prompt
Machine Number" task OR the legacy "Check Machine Number" task as
"ON" so old bays still register correctly. Toggle OFF unregisters
all three names (Prompt + Apply + legacy) for clean removal.
OLD design: a single 'Check Machine Number' scheduled task ran as the
logged-in user (BUILTIN\Users, Limited) on AtLogOn. It both showed the
InputBox AND tried to update HKLM\SOFTWARE\WOW6432Node\GE Aircraft
Engines\DNC\General + C:\ProgramData\UDC\udc_settings.json. To make
those non-admin writes possible, 02-MachineNumberACLs.ps1 pre-granted
BUILTIN\Users SetValue + Modify on those targets during imaging.
Three problems with that:
1. SECURITY: any logged-in user could overwrite the machine-identity
reg key.
2. FRAGILE: ACL grants raced with eDNC install timing on some bays
(eDNC reg key didn't exist yet when 02-MachineNumberACLs ran;
OpenSubKey returned null, ACL silently skipped, Check-MachineNumber
later failed with PermissionDenied).
3. SILENT-SUCCESS BUG: Update-MachineNumber's Set-ItemProperty calls
lacked -ErrorAction Stop. PermissionDenied is a non-terminating
error in PS5.1, so the try/catch never fired. The script set
$out.EdncUpdated=$true anyway and the dialog reported success
while the reg value stayed at 9999. WJF capture log on FGY07FZ3
shows this exact pattern.
NEW design - two scheduled tasks split by responsibility:
- "Prompt Machine Number" : AtLogOn trigger, BUILTIN\Users (Limited).
Reads current values (read-only). If 9999, shows InputBox. Writes
typed number to C:\Logs\SFLD\machine-number-request.txt. Triggers
SYSTEM Apply via schtasks /run. Polls for result JSON (60s timeout).
Shows result MessageBox with TopMost so it isn't hidden behind
other windows.
- "Apply Machine Number" : on-demand, SYSTEM (Highest). Reads the
request file, calls Update-MachineNumber (full HKLM + ProgramData
access from SYSTEM context). Pulls per-machine NTLARS .reg + UDC
settings JSON + UDC live data from the SFLD share if site-config
has share paths. Writes result JSON. Removes request file.
Unregisters the Prompt task on full success (Prompt itself can't
self-unregister - Limited users can't delete a SYSTEM-owned task).
- Default task SDDL only allows Admins + SYSTEM to read/run a
SYSTEM-owned task. Added BUILTIN\Users GR+GX ACE via COM
SetSecurityDescriptor so the Limited Prompt task can schtasks /run
Apply on demand. They can read + execute it; not modify or delete.
- Update-MachineNumber.ps1 writes now have -ErrorAction Stop so
PermissionDenied actually fires the catch block instead of being
swallowed.
- 02-MachineNumberACLs.ps1 gutted to a no-op (left in place for
Stage-Dispatcher discovery; no longer grants the ACLs). Old bays'
existing grants are harmless since SYSTEM ignores them.
- Register-CheckMachineNumberTask.ps1 now installs both tasks AND
unregisters the legacy 'Check Machine Number' task name on
re-imaging. Run-ShopfloorSetup.ps1's $skipInBaseline list now
includes Prompt-MachineNumber.ps1 + Apply-MachineNumber.ps1 so
they aren't auto-run during the baseline pass (only via the
scheduled tasks).
Smoke tested end-to-end on win11 VM with ShopFloor (Limited) logging in
interactively: AtLogOn trigger fired Prompt, dialog rendered, tech
typed 7777, schtasks /run succeeded (the SDDL fix lets Limited users
trigger SYSTEM tasks), Apply ran as SYSTEM, eDNC reg + machine-number.txt
both updated to 7777, result MessageBox shown, Prompt task auto-
unregistered by Apply's cleanup step. No ACL grants needed on any user.
Apply also re-tested with -ErrorAction Stop confirming non-terminating
PermissionDenied now properly throws into the catch + populates Errors[]
+ flips $out.EdncUpdated to false - so any future write failures will
report honestly instead of silently claiming success.
Bay's ShopFloor user account exists but has never logged in at imaging
time, so its NTUSER.DAT doesn't exist yet and we can't reg-load its
hive to remap source SID -> ShopFloor SID. The in-line restore at
09-Setup Step 3b handles HKLM (controller config, device-map) + files,
but per-user prefs (LouteditS Layout, Page margins, Recent Files, ~2700
rows in a typical WJF capture) get skipped.
Fix: register a SYSTEM-context scheduled task at imaging time that
fires AtLogOn UserId=ShopFloor. When ShopFloor first logs in, Windows
loads their NTUSER.DAT automatically; task fires (running as SYSTEM
so lockdown policies on ShopFloor's user-context don't block HKLM
writes via the same Install script); SID-remap path finds the live
hive and writes prefs into HKEY_USERS\<ShopFloor-sid>. Task writes a
flag file + unregisters itself after one successful run.
Pieces:
- Install-FormtracepakSettings.ps1: new -HKEYUsersOnly switch that
skips the HKLM .reg files + HKLM CSV rows (already restored at
imaging time). Fallback user chain ShopFloor->SupportUser->$USERNAME.
- Schedule-WaxTracePerUserRestore.ps1: registers the task, writes
C:\WaxTrace-Install\Run-WaxTracePerUserRestore.ps1 task action which
invokes Install with -HKEYUsersOnly and self-cleans on success.
- 09-Setup-WaxAndTrace.ps1 Step 3b: in-line restore now uses
-RestoreRegistry -RestoreData -RestoreConfig (HKLM + files now);
calls Schedule-WaxTracePerUserRestore.ps1 to queue HKEY_USERS for
first ShopFloor logon.
- sync-waxtrace.sh: pushes Schedule-WaxTracePerUserRestore.ps1 to
PXE share alongside Install-FormtracepakSettings.ps1.
Smoke tested on win11 VM partially: task registration works, manual
trigger fires + self-unregisters cleanly, flag file lands. Real per-
user SID-remap happens at first ShopFloor logon (can't simulate from
qga without an interactive ShopFloor session).
Three speed bumps on the waxtrace WinPE stage:
- /MT:16 on the bundle robocopy (was single-thread). Parallelizes the
small-files-many-of-them part (config + backups + prereqs).
- /J on the single-file FTPak ISO cherry-pick. Unbuffered I/O is
measurably faster than xcopy on 2 GB-ish files over SMB; xcopy goes
through the buffered I/O path which double-copies in kernel.
- Swap the FTPak ISO cherry-pick from xcopy to robocopy single-file
syntax (source dir + dest dir + filename pattern) so we can use /J.
No behavioral change otherwise. Backup ZIP cherry-pick stays on xcopy
(it's ~1 MB, doesn't benefit from /J).
WJF00159 imaging pass on 2026-05-24 logged:
[ERROR] waxtrace-manifest.json not found at
C:\WaxTrace-Install\waxtrace-manifest.json
even though the manifest is present on the PXE share. Root cause: the
xcopy approach copied EVERYTHING including the 12+ GB formtracepak\
directory of vendor ISOs, then deleted formtracepak\ afterward and
re-created it with just the one matched ISO. The /EXCLUDE:NUL placeholder
("pass NUL device as exclude-file") was silently ignored by xcopy in
WinPE, and the redirection >/dev/null 2>/dev/null hid any errors. The copy was
either aborting mid-stream (running out of patience / disk / connection)
or the manifest landed but got clobbered in the rmdir/recreate dance.
Switch to robocopy /XD formtracepak which excludes the dir up front so
we never even attempt the 12 GB of ISOs. Keep /NFL /NDL to suppress
per-file listing but leave overall output visible (no >/dev/null) so any
failure is debuggable from the install log. Check errorlevel >= 8
explicitly (robocopy exit codes 0-7 are all "OK").
Smoke tested on win11 VM with a representative tree (manifest +
bay-config + backups\WJF00159.zip + prereqs\hasp.exe + dummy
formtracepak\ ISOs): formtracepak\ excluded, all other files +
sub-dirs copied cleanly, exit 1 (= OK).
Pushed to boot.wim.with-ps (the correct PowerShell-bearing wim - the
one I had been editing before was missing powershell.exe) and deployed
to /var/www/html/win11/sources/boot.wim on 172.16.9.1.
Picker was still pointed at calibrations/INDEX.csv, which only listed
14 bays that have a per-asset cal ISO ripped. Three bays we just
refreshed into bay-config.csv (WJF00450, WJF00461, WJRP0423) had no
cal-disc entry, so they fell off the menu and tech had to drop to the
free-text prompt to type the asset by hand - felt like a regression.
Two changes:
- select-waxtrace-asset.ps1: prefer bay-config.csv when -IndexPath
points there (now the default). Auto-detect schema by checking for
the ftpak_version column. Display columns become
ASSET / FTPAK / MODEL / USER ID so the tech can confirm bay metadata
at a glance before pressing Enter. Falls back to
calibrations/INDEX.csv if bay-config.csv missing.
- startnet.cmd: invoke the picker with -IndexPath bay-config.csv.
Pushed: both boot.wim copies refreshed via wimupdate, new
select-waxtrace-asset.ps1 deployed to PXE share, new boot.wim landed
at /var/www/html/win11/sources/boot.wim on 172.16.9.1.
bay-config.csv parent-dir copy synced with scripts/bay-config.csv so
resolve-bay-config.ps1 (called from startnet.cmd in WinPE) and the
picker both see the same 17-bay set.
Wires the three pieces that make the per-bay backup restore happen as
part of the PXE imaging pass, no manual post-imaging step required:
1. sync-waxtrace.sh: stage per-asset backup ZIPs from
/home/camp/pxe-images/wt/<asset>/formtracepak_backup_*.zip (newest)
into installers-post/waxtrace/backups/<asset>.zip on the PXE share.
Also pushes scripts/Install-FormtracepakSettings.ps1 alongside the
bootstrap bundle so 09-Setup can call it post-vendor-install.
2. startnet.cmd: after the FTPak ISO cherry-pick, xcopy
Y:\installers-post\waxtrace\backups\%MACHINENUM%.zip to
W:\WaxTrace-Install\backup\%MACHINENUM%.zip. Logs INFO if no per-asset
ZIP exists - 09-Setup will then skip the restore step.
3. 09-Setup-WaxAndTrace.ps1 Step 3b: between cal ISO and OpenText
auto-start steps, look for C:\WaxTrace-Install\backup\<asset>.zip
and invoke Install-FormtracepakSettings.ps1 -BackupPath ...
-RestoreData -RestoreConfig -Force. Registry restore is intentionally
omitted - captured HKLM is overwritten by the vendor MSI install in
Step 2 anyway, and captured HKEY_USERS would land at the source
bay's SID (which doesn't exist on the freshly imaged bay).
bay-config.csv refresh: 17 captured bays with full version/model/
user_id/hw_sn/hw_id/host. Versions stick to the original bay-config.csv
target values where the live binary drifted to a release we don't have
an ISO for (e.g. WJRP2035 live 5.7.0.82 -> imaging targets 6.0).
WJF00450 flagged MISSING_DATA in user_id + hw_id columns so the
imaging path aborts cleanly until the dongle is read.
Smoke tested on win11 VM with WJF00545's real capture: staged the
expected bay-side layout (C:\WaxTrace-Install\Install-FormtracepakSettings.ps1
+ C:\WaxTrace-Install\backup\WJF00545.zip), invoked the resolve +
call path from a simulated Step 3b - 17 files restored cleanly, 0
errors.
WJF00052 / WJF00083 / WJF00084 / WJF00159 produced 0-byte ZIPs on the
2026-05-24 capture pass. Export-FormtracepakInventory was the primary
culprit (Get-Service hang, fixed in d359563), but Backup has the same
root failure mode for the same bays: reg.exe export via Start-Process
-Wait and the recursive Get-ChildItem walk over HKLM:\SOFTWARE\
WOW6432Node\Mitutoyo (95k+ values) both lack timeouts, so a degraded
SCM / antivirus interception / WMI repository on the bay can wedge the
script and the operator kills the .bat - same outcome as the inventory
hang.
Two timeout fences:
- reg.exe export: switch from Start-Process -PassThru -Wait to
[System.Diagnostics.Process]::Start + WaitForExit(300_000). If the
process hasn't exited after 5 minutes, Kill() it and log + count an
error; the .reg file for that one root is skipped but other roots
+ the CSV fallback + the file/data captures continue. Bonus: the
ProcessStartInfo path also gives reliable $proc.ExitCode access; the
Start-Process -PassThru object sometimes returned a stub with
unpopulated ExitCode, producing a false "reg.exe exit for ..."
warning even on successful exports.
- Recursive Get-ChildItem CSV walk: move into a Start-Job + Wait-Job
-Timeout 600 (10 min). If the walk hangs, Stop-Job, log, increment
error count, .reg file remains authoritative for that root.
Also fixed a subtle Start-Job return-shape bug introduced in the same
edit: emitting the rows via the pipeline inside the job + Receive-Job
flattens correctly, whereas `return ,$list` wrapped the whole List in a
single-element array, so the outer foreach was treating the list-of-95k
as a single row. Net effect was Registry Values: 4 instead of 95152 in
the manifest. Verified fixed via a full real-install run on the VM:
95152 values captured cleanly in 22 s, 0 errors.
Net behaviour: the failed-bay re-runs (WJF00052/00083/00084/00159)
should now either produce real ZIPs or print a clear warning naming the
specific reg root that hung, instead of leaving an empty ZIP behind.
WJF00052 / WJF00083 / WJF00084 / WJF00159 hung indefinitely on step [5/5]
during the 2026-05-24 capture pass and the operator killed the .bat,
leaving empty inventory CSVs. The earlier Start-Job + Wait-Job -Timeout 30
guard (commit fce6680) was insufficient: Stop-Job on a Get-Service that's
blocked on a degraded Service Control Manager can itself block in the SCM
call (Sentinel HASP driver service in particular has been observed to
wedge Get-Service for minutes), so the main script never unblocked even
after the 30s timeout fired.
Service state isn't load-bearing for identifying the install on a bay
(version + model + DeviceName come from disk + registry, not the SCM),
so the cleanest fix is to drop the Get-Service block entirely. Get-Process
is fast and stays. Step [5/5] label changed from "Checking running
processes and services" to "Checking running processes".
Smoke tested on win11 VM: full Export against a real v6.213 / AVANT
install completes in ~25 s (was 2.9 s with no install, 25 s now reflects
the legitimate ~95k registry walk that dominates the runtime - not the
service hang).
Installed FormTracePak v6.213 on the win11 VM (picking FORMTRACER Avant
in the dialogs) and probed the resulting registry / disk layout to find
out what evidence a real FormTracePak install actually carries. Two
empirical findings:
1. ACTIVE MODEL lives at
HKLM:\SOFTWARE\WOW6432Node\Mitutoyo\FORMPAK\Config\device map\DeviceName
(string value). For the AVANT install the value is "FORMTRACER Avant";
for the CV/SV/CS controllers the value contains the matching model id.
The Surfpak\FormMes\MachineInfo\Machine\Machine* subtree lists EVERY
supported machine and is NOT the active selection - the previous
heuristic that scanned uninstall-entry DisplayName picked up bogus
WinUSB driver-package entries from "Mitutoyo Corporation" instead.
2. INSTALLED BINARY VERSION is in Formtracepak.exe VersionInfo:
FileVersion=6.2.0.51, ProductVersion=6.2.0.0. This does NOT match the
Mitutoyo MSI release label ("6.213") that bay-config.csv uses. The
uninstall entry's DisplayVersion is empty. So bay-config.csv stays
canonical for the per-asset marketing version; exe FileVersion is a
concrete cross-check.
Backup rewrites:
- Replace the previous one-shot version detection with evidence reading:
bay-config.csv (asset->version+model), Formtracepak.exe VersionInfo,
device-map\DeviceName. The over-broad uninstall-reg regex is gone.
- Normalize DeviceName ("FORMTRACER Avant" / "CV-4500" / "CV-3200" /
"Contracer" / "Surftest") to bay-config notation (AVANT / CV-4500 / ...).
- Emit BayConfigMatch flag - true when bay-config-predicted model agrees
with the device-map\DeviceName on disk. False = drift, tech rechecks
before restoring to a new bay.
- manifest.json now stamps: AssetNumber, FormtracepakVersion, Model,
BayConfigVersion, BayConfigModel, BayConfigSource, InstalledExeVersion,
InstalledExePath, InstalledDeviceName, InstalledModelNormalized,
BayConfigMatch.
HKEY_USERS sweep:
- Wax/Trace bays log in as a per-site user (lg782713sd at WJ today,
ShopFloor post-SFLD-2.0, other accounts at other sites). The previous
HKCU:\ scan only captured the script's running user. Sweep every
loaded HKEY_USERS hive whose SID matches S-1-5-21-* (real user SIDs)
for Software\Mitutoyo / FORMTRACEPAK / FORMPAK / SURFPAK subkeys,
add them to $RegistryRoots. Username-agnostic - works at any site
without changes.
reg.exe export now also accepts the Registry::HKEY_USERS\<sid>\... PSPath
form by stripping the "Registry::" prefix when building the reg.exe
argument (previously emitted "Invalid key name" errors on HKEY_USERS roots).
Smoke tested against a real v6.213 / FORMTRACER Avant install on win11
VM: bay-config lookup matches, exe FileVersion read, device-map
normalized to AVANT, all four .reg files (HKLM, HKLM-WOW6432Node, HKCU,
HKEY_USERS\<interactive-sid>) exported clean, 0 errors.
Restore-side SID translation (HKEY_USERS\<src-sid>\... -> target user's
SID or HKCU on the new bay) is a follow-up. HKLM tree carries the
critical device-map\DeviceName, controller config, and machine settings;
the HKEY_USERS hive captures per-user UI prefs only.
Backup-FormtracepakSettings observed 17 Errors on a real shopfloor PC
(G5PRTW04ESF / WJF00159 capture) - all of the form:
WARNING: Failed to copy ...App.ini: Exception calling ".ctor" with "0"
argument(s): "This implementation is not part of the Windows Platform
FIPS validated cryptographic algorithms."
Cause: Windows FIPS policy is enabled on West Jefferson shopfloor PCs.
The per-file Get-FileHash -Algorithm MD5 call throws a hard .NET exception
that bypasses -ErrorAction SilentlyContinue (the throw is from the MD5
constructor, not the cmdlet's parameter binder). That exception was caught
by the broad try/catch around both Copy-Item + manifest add, producing a
misleading "Failed to copy" message even though Copy-Item already succeeded.
Net effect: files copied fine, but manifest rows were missing for those
files (Install would fall back to its bulk-copy path).
Two fixes:
- Switch the hash algorithm from MD5 to SHA256 in both Backup (manifest
row capture) and Install (Restore-FileItem hash-skip compare). SHA256
is Get-FileHash's default and is FIPS-compliant. Old MD5-hashed backups
remain restorable because Install computes hashes fresh from disk at
restore time and does not read the Hash column from file_manifest.csv.
- Split the broad try/catch in Backup's Copy-ToStaging into two
try/catches: the first wraps only Copy-Item (real copy failure -> Errors
counter + skip the file), the second wraps only Get-FileHash (hash
failure -> log warning, manifest row gets a null Hash and is still
recorded). A hash failure no longer pretends the copy failed.
- Install's hash compare is wrapped in try/catch too so a hash exception
falls through to overwrite-mode rather than crashing the restore.
Smoke tested on win11 VM: SHA256 round-trip works (64-char hashes in
file_manifest.csv), Backup reports 0 Errors, Install hash-skip path
correctly skips Identical files on second-run idempotency check.
Two operator-driven fixes.
1. Backup target moves from S:\2 WJ Scans Record Retention\backup\waxtrace
to S:\DT\Shopfloor\backup\waxandtrace per the canonical SFLD layout.
Backup creates the per-asset folder if missing; Install reads from the
same path by default.
2. Export-FormtracepakInventory hung on step [5/5] when run on a shopfloor
PC. The original `Get-Service | Where-Object { DisplayName -match ... }`
pattern materializes every service via the Service Control Manager + post
filters in PowerShell, which can block indefinitely when any single
service (Sentinel HASP driver, GE-Enforce agent, etc.) is in a degraded
state. Two-part fix:
- Switch to Get-Service -DisplayName 'Mitutoyo*','*FORMTRACEPAK*',...
so the SCM only materializes matching services (server-side wildcard
filter, faster + lower blast radius).
- Wrap the enumeration in Start-Job + Wait-Job -Timeout 30 so a
degraded SCM aborts gracefully with a warning rather than wedging
the whole inventory pass.
Smoke tested on win11 VM: full Export run with the new code completes in
2.9 s and emits the inventory CSV correctly.
Tech ran Export-FormtracepakInventory.ps1 from S:\DT\shopfloor\scripts\
waxandtrace\ and the picker fired correctly but Export-Csv failed with
'Cannot bind argument to parameter Path because it is an empty string'.
Root cause: $OutputPath defaulted to $PSScriptRoot and $PSScriptRoot came
through empty in that invocation path (suspected ISE / IEX-style host or
remote wrapper). On a [string] param, $null/empty default coerces to ''
and Join-Path then errors.
Fix in all three triad scripts: resolve a local $scriptDir via a fallback
chain ($PSScriptRoot -> $PSCommandPath -> Get-Location), and use that
instead of $PSScriptRoot for sibling lookups (Select-WaxtraceAsset.ps1,
bay-config.csv).
Export additionally:
- Drops the $OutputPath = $PSScriptRoot param default in favor of the
same fallback chain.
- Tests / creates $OutputPath BEFORE the 90k-item registry scan so a bad
output dir surfaces immediately instead of after a long scan.
Smoke tested on win11 VM: explicit -OutputPath '' now resolves to a
writable directory and the CSV writes successfully.
Two operator-UX improvements for the Backup / Export / Install triad.
1. Backup target moves from \\tsgwp00525\...\formtracepac to S:\2 WJ Scans
Record Retention\backup\waxtrace\<asset>\. S: is mapped at shopfloor
imaging time and stays mapped post-categorization, so the same default
path works whether the operator runs the backup on an old bay (manual
pre-image capture) or a freshly imaged one. The destination directory
is created if missing.
2. New Select-WaxtraceAsset.ps1 - arrow-key bay picker patterned after
the WinPE select-waxtrace-asset.ps1. Reads bay-config.csv (sibling
file), shows asset_tag + ftpak_version + model + user_id per row, and
returns the selected asset_tag via stdout. Falls back to a manual
entry prompt if the CSV is missing or the operator picks "Other".
Backup / Export / Install now invoke the picker when interactive AND
bay-config.csv is alongside the script. Non-interactive paths
(qga / SYSTEM / scheduled task) keep silently defaulting to
COMPUTERNAME so unattended runs are unchanged.
Export gained an -AssetNumber parameter and stamps it into the output
CSV filename so multiple inventories from the same host stay
distinguishable when the operator is auditing several bays in a row.
bay-config.csv is copied into the scripts\ dir so the picker has a
source of truth that ships next to the scripts (and into pxe-images
for tech distribution).
Smoke tested on win11 VM: all four PS1 parse-clean, non-interactive
backup path still produces a valid ZIP (silent COMPUTERNAME default),
picker handles missing-CSV gracefully (manual-entry fallback). The
arrow-key UX itself is operator-verifiable only on a real terminal.
Three fixes in Backup / Export / Install, validated end-to-end on the win11 VM
against a seeded HKCU\SOFTWARE\Mitutoyo\Formtracepak key carrying all five
registry value types (String, DWord, ExpandString, MultiString, Binary).
1. Registry corruption on REG_BINARY / REG_MULTI_SZ restore
Backup wrote those values to registry_values.csv via [string]$val, which
lossily coerces a byte[] to "System.Byte[]" and a string[] to a
space-joined scalar. Install's CSV restore loop runs AFTER the .reg file
import (which is lossless), so the CSV pass overwrites the good values
with corrupted strings. Two-part fix:
- Backup: skip Binary / MultiString / None / Unknown when writing the CSV.
Only String, ExpandString, DWord, QWord roundtrip cleanly through
New-ItemProperty -PropertyType, so capture only those. The .reg file
remains authoritative for the rest.
- Install: defensive filter on the CSV restore loop that skips any row
whose Type is not in {String, ExpandString, DWord, QWord}. This catches
legacy CSVs already on the share that were taken before this fix.
2. v6.213 vendor install path not scanned / not restored to
The per-bay FormTracePak install (commit 54dddaa) lands under
C:\Program Files (x86)\MitutoyoApp\Formtracepak, but the search-path
lists in Backup + Export only covered C:\...\Mitutoyo (no MitutoyoApp).
Result: a backup taken on a freshly imaged v6.213 bay produced Config
Files = 0 because the script never looked at the actual install dir.
Added MitutoyoApp (x86 + native ProgramFiles) ahead of the legacy
paths in all three scripts.
3. Install $DefaultAppTargets fallback didn't include MitutoyoApp either,
so a restore from an OLDER bay (source path C:\Mitutoyo\...) onto a
freshly imaged v6.213 bay would fall back to ProgramFiles\Mitutoyo
(does not exist), miss the MitutoyoApp\Formtracepak tree, and write
the restored files into the first existing legacy path. Added the
MitutoyoApp entries at the top of the ordered fallback table.
Smoke tested on win11 VM: backup of all 5 reg types, then corrupt every
value, then Install -RestoreAll restores all 5 byte-exact (incl. REG_BINARY
DE-AD-BE-EF-CA-FE-BA-BE-01-02-03-04 and REG_MULTI_SZ alpha.smp/beta.smp/
gamma.smp). Verified legacy poison-CSV path triggers the defensive filter
and the .reg-imported values survive untouched. -DryRun confirmed
non-mutating. Idempotency confirmed via hash-skip.
Bays span 7 FormTracePak versions (5.510 - 6.213) and 3 sub-versions
(AVANT / CV-4500 / CV-3200), each with a unique licensing USER ID. Previously
all bays got v6.213 with no model/USER hint to the tech.
- bay-config.csv: 15 rows mapping asset_tag to ftpak_version + model + user_id.
- resolve-bay-config.ps1: WinPE-runnable resolver. Looks up the asset and
writes version.txt / model.txt / userid.txt / bay-info.txt under
W:\Enrollment\waxtrace\.
- startnet.cmd: xcopy WaxTrace bundle minus formtracepak\, invoke the
resolver with %MACHINENUM%, then cherry-pick only the matching
FORMTRACEPAK-V<ver>.iso (~2 GB local vs ~12 GB if all were staged).
- 09-Setup-WaxAndTrace.ps1: read the per-bay files, mount the right ISO,
drop <asset>-FTPak-install-info.txt on SupportUser's desktop, and print
a banner with MODEL + USER ID so the tech has them top-of-mind when
Setup.exe dialogs come up.
- sync-waxtrace.sh: loop over all FORMTRACEPAK-V*.iso instead of hard-coding
v6.213; also push bay-config.csv + resolve-bay-config.ps1 to the share.
- Drop -Physical + MediaType filter from Get-NetAdapter; some OEM driver
stacks report HardwareInterface=False or localize MediaType, hiding the
Realtek controller NIC from the previous query.
- Refine corp-vs-controller classification: skip only if a gateway is set
AND it's not 192.168.1.x, OR if the IP looks corp (10.x / 172.16-31.x).
Keep candidates that are unconfigured, link-local, or 192.168.x.
- Disable DHCP in both PersistentStore and ActiveStore before New-NetIPAddress
to avoid "Inconsistent parameters PolicyStore PersistentStore and Dhcp
enabled" failures.
- Fall back to netsh interface ip set address when the PS cmdlets still
fight each other; netsh writes both stores cleanly.
Pre-2026-05 Keyence images didn't write pc-subtype.txt via startnet.cmd. Without
a subtype the share manifest's per-model PCTypes gate falls back to the default
(VR-6000), causing the wrong model to install on VR-3000 / VR-5000 boxes.
Detect the installed VR-3000/5000/6000 by its uninstall ProductCode and
persist the subtype so subsequent GE-Enforce cycles + the share manifest gate
route correctly.
Pair of operational tools used when a wax/trace bay's cal apply fails
(218-378-13 series cal Setup.exe crash, or any future variant). Were
living in /home/camp/pxe-images/ on the workstation; promoting to the
repo so they ship with the codebase, get version-controlled, and can
be pushed onto each PXE server's enrollment share via the standard
sync flow.
debug-waxtrace-cal.ps1 (+ .bat launcher):
- 9-section forensic walkthrough that runs on the bay as admin.
- Autodetects FormTracePak install location, dumps data/ dir contents,
finds + mounts the per-asset cal ISO, lists its contents, checks the
on-disk 09-Setup-WaxAndTrace.ps1 for the direct-copy bypass marker,
greps the imaging-time log for cal lines, pulls the last 24h of
.NET Runtime / Application Error / WER events related to Setup.exe.
- Output: C:\Logs\WaxTrace\debug-waxtrace-cal.log
fix-waxtrace-cal.ps1 (+ .bat launcher):
- Idempotent recovery: mounts the bay's cal ISO, unconditionally copies
data\* into FormTracePak's data dir, renames any filename containing
' _' (space-underscore) to drop the embedded space, clears read-only,
dismounts. Works on both 218-378-13 (broken filenames) and 218-458A
(clean filenames) since the rename is a no-op when no space is
present. Bypasses the buggy vendor cal Setup.exe entirely.
- Output: C:\Logs\WaxTrace\fix-waxtrace-cal.log
Both already pushed to \\172.16.9.1\enrollment\tools\ on both PXE
servers earlier today; this commit lands them in the repo as the
source of truth so future PXE server builds + ad-hoc rsyncs pick
them up automatically.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The direct-copy bypass added earlier was never firing - Get-ChildItem -Filter
uses Win32 filename filtering and does NOT honor PowerShell wildcards or
character classes. The previous detection filter '*[0-9] _*.txt' matched
literal bracket-zero-through-nine text, which never appears in any
filename. $hasBrokenFilenames was therefore always False, and every
218-378-13 series cal apply fell through to the vendor setup.exe which
crashes with System.ArgumentException (exit -532462766).
Confirmed via debug-waxtrace-cal.ps1 log on WJF00159: section 6 reports
the on-disk script has the direct-copy fix, section 7 shows the actual
runtime log line 'running cal Setup.exe' followed by exit -532462766.
The "fix" was never executing because the gate was broken.
Replace -Filter with Get-ChildItem -File + Where-Object regex match on
' _\d+\.txt$' which catches the actual buggy filename pattern (space-
underscore-digits-.txt at end of name) regardless of probe series.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Removed the placeholder DODA entry from Applications so a bay imaged
with the 'With DODA' submenu choice today does not log a 'Installer
not found: DODA-PLACEHOLDER.exe' error per cycle. Wiring is otherwise
unchanged: startnet.cmd still offers the With-DODA submenu, pc-subtype.txt
is still written as 'doda', and 09-Setup-CMM.ps1 still passes PCSubType
through to Install-FromManifest. When the DODA installer is sourced,
move the entry from _pending_doda_entry back into Applications (engine
ignores any top-level field other than Version + Applications).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Carries over the lessons learned from wax/trace + Keyence imaging today
and threads the same pattern through the CMM path.
09-Setup-CMM.ps1:
- Pass PCType + PCSubType to Install-FromManifest so the manifest's
per-entry PCTypes filter is honored. Without this every entry runs
regardless of bay variant - the same bug Keyence had before per-model
gating was added.
- Move bootstrap cleanup to a conditional that only deletes
C:\CMM-Install once every (filter-applicable) manifest entry detects
as installed. If a Hexagon installer forces an unplanned reboot
mid-install, the new Run-ShopfloorSetup self-resume RunOnce fires on
the next auto-login; the staging dir needs to still be on disk for
the re-run to recover. Logs "retained ... not all entries installed
yet - will retry on next self-resumed run" when partial.
cmm-manifest.json:
- Drop exact DetectionValue from PC-DMIS 2016, PC-DMIS 2019 R2, CLM
1.8.73, and goCMM. Detection is now uninstall-key presence only, so
a Hexagon security patch that bumps the DisplayVersion does not
trigger a re-install loop with exit 1638 every GE-Enforce cycle.
Bumping the installer in apps/ is the upgrade path - manifest engine
detection should not also be a version drift catcher for vendor MSIs
whose backward-compat is established by the vendor.
- Specific to goCMM: the installer filename version (1.1.6718.31289)
does not match what the installer registers under its uninstall key.
Dropping DetectionValue silences the false-mismatch loop the prior
version would have triggered.
- Add DODA placeholder entry gated to PCTypes=["cmm-doda"]. Real
Installer filename, args, and DetectionPath still TODO once the
DODA binary is sourced + dropped at installers-post/cmm/.
startnet.cmd:
- Add :cmm_submenu after the user picks gea-shopfloor-cmm from the
main menu. Two options: Standard (default PC-DMIS + CLM + goCMM
+ Protect Viewer) or With DODA. Mirrors :keyence_submenu pattern.
- Write CMMVARIANT to W:\Enrollment\pc-subtype.txt so Install-FromManifest
on the bay can apply the PCTypes filter against gea-shopfloor-cmm-doda.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The :prompt_waxtrace_asset picker block maps Y: to the enrollment share
so select-waxtrace-asset.ps1 can read INDEX.csv. The later :skip_machinenum
block also runs `net use Y: \\172.16.9.1\enrollment ...` to keep the share
mounted through the rest of imaging, but Y: is already mapped at that
point so the second net use throws "System error 85: The local device
name is already in use". Harmless (script proceeds and "the command
completed successfully" prints right after) but visible noise to the
operator during PXE imaging.
Gate the second net use behind `if exist Y:\` so we only map when Y: is
not already mounted. Same end state, no error message.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Imaging chain stalled on WJF00159 after FormTracePak Setup.exe forced
a reboot: SupportUser auto-logged in fine, briefly flashed something
(an HKLM\Run logon hook), then idle - no resume of Run-ShopfloorSetup.
Confirmed via diag-dispatcher.ps1: bay had AutoLogon working, RunOnce
empty, no Stage-Dispatcher.ps1 on disk, no setup-stage.txt.
Root cause: Run-ShopfloorSetup launches once from unattend XML's
FirstLogonCommands and has no self-resume mechanism. If anything cuts
it off mid-flight (FormTracePak Setup, eDNC MSI, Oracle install with
forced reboot, etc) the chain dies and nothing brings it back.
Stage-Dispatcher.ps1 in the repo is academic infrastructure that was
never wired into the live flow - startnet.cmd does not stage it and
nothing creates setup-stage.txt.
Fix: have Run-ShopfloorSetup register ITSELF as RunOnce at the top of
the script. The script is idempotent throughout (detection checks
skip already-done work) so re-entry post-reboot picks up cleanly.
Normal completion path removes the RunOnce so it does not re-fire
after the planned end-of-script reboot.
Also top up AutoLogonCount to 10 at script start. The unattend XML's
LogonCount=7 budget gets consumed across typical imaging reboots
(Office, Oracle, FormTracePak, Run-ShopfloorSetup explicit, sync-intune)
and an unplanned FormTracePak forced reboot pushes the counter past 0,
clearing AutoAdminLogon and parking the bay at the login screen.
Restoring the budget every Run-ShopfloorSetup entry keeps SupportUser
auto-logging in across any number of forced reboots until normal
completion. Lockdown's Autologon.exe sets its own AutoAdminLogon for
the ShopFloor user when it runs, so the post-completion natural
decrement to 0 does not affect the final state.
Verified via diag-dispatcher.ps1 capture on WJF00159 today - that bay
had AutoLogonCount=4 and no Stage-Dispatcher.ps1 on disk, which both
match this root cause + fix.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Unattend XML sets LogonCount=7 for SupportUser autologon. Each interactive
login decrements the counter; at 0 Windows clears AutoAdminLogon and the
bay parks at the login screen with no one to fire RunOnce -> dispatcher
never re-runs -> imaging chain stalls.
Typical imaging burns several logons: Windows OOBE first logon,
post-Office reboot, Oracle install reboot, FormTracePak Setup.exe forced
reboot, Run-ShopfloorSetup's own shutdown /r at end of script, stage
advances. The unplanned FormTracePak reboot pushes the count past 0 on
some bays - the exact failure mode the WJF00159 imaging today hit, where
Stage-Dispatcher.ps1 had the new defensive RunOnce-re-register fix
landed but the dispatcher still never re-fired because there was no
auto-logon to trigger it.
Top up AutoLogonCount to 10 every time the dispatcher hits the
'shopfloor-setup' stage. Restores the autologon budget across any
vendor-forced reboots that fire during the stage. When sync-intune
finishes the whole pipeline, AutoLogonCount is left to decrement
naturally; by then lockdown's Autologon.exe has set its own
AutoAdminLogon for the ShopFloor user.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
User received three PowerShell scripts from a Mitutoyo source for
backing up + restoring FormTracePak settings per asset:
Export-FormtracepakInventory.ps1 - audit: enumerate files + reg keys
Backup-FormtracepakSettings.ps1 - capture: config + data + reg into
timestamped ZIP, manifest-driven
Install-FormtracepakSettings.ps1 - restore: replay ZIP to a new bay,
hash-skip identicals, backup
existing as .pre_restore_bak
Cleanup pass over the vendor-shipped versions:
- Strip Unicode box-drawing characters from banners (ASCII-only policy)
- Install: switch to [ordered]@{} for DefaultAppTargets/DefaultDataTargets
so fallback priority is deterministic
- Install: add -AssetNumber gate that defaults to per-asset SFLD path
\\tsgwp00525...\Shopfloor\backup\formtracepac\<AssetNumber>
- Install: timestamp the .pre_restore_bak filename so re-runs don't
clobber the previous backup
- Install: handle BackupPath being a directory containing
formtracepak_backup_*.zip files (picks newest)
- .bat launchers for each PS1 (bypass execution policy, double-click)
Not yet wired into 09-Setup-WaxAndTrace.ps1; pending reference-backup
capture from a known-good bay before promoting to imaging path. Today
the V6.213 vendor MSI install + per-asset cal ISO still handle the
imaging-time setup directly.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
04-SetControllerNicIP.ps1 (imaging-time, runs once via Run-ShopfloorSetup):
- Finds the Realtek physical Ethernet adapter (controller NIC on every
collections bay; corp LAN is Intel)
- Skips any candidate with a DHCP default gateway (that one is the corp
LAN, not the controller)
- Skips any candidate already on 192.168.1.2
- Sets static 192.168.1.2/24, no gateway, clears DNS - matches the
manual procedure documented in post-deploy-debug-flowchart.md section 2B
- Refuses to guess when multiple Realtek NICs remain ambiguous
- Imaging-time only, not enforced via GE-Enforce so the tech can override
on a specific bay if needed without the drift-catcher reverting
Set-ControllerCredential.ps1 + manifest-entry-controller-credential.json:
- Break-glass cmdkey /add for the controller SMB share (\\192.168.1.1\md1
used by DNC). Scoped to the 12 Okuma LOC650 machine numbers (3201-3212).
- Manifest entry is detection-less so it runs every enforce cycle if the
script is armed (.ps1 extension); disarmed by default (.ps1.bak on the
share) so a coach can rename when a bay loses its credential without
the enforcer overwriting per-bay deviations between events.
- Smoke-tested end-to-end on win11 VM via QGA: SYSTEM context cmdkey /add
succeeds, cmdkey /list shows the entry. DNC service runs as LocalSystem
so SYSTEM vault is the right target.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
If a bay is imaged with the 9999 placeholder (tech leaves the WinPE
prompt blank or types 9999), the lockdown+auto-login chain ends up at
the ShopFloor user with no real machine number. We had Check-MachineNumber.ps1
written - InputBox + Update-MachineNumber pulls per-machine NTLARS .reg
+ udc_settings_<N>.json from the SFLD share - but it only got registered
when a tech manually ran Configure-PC + toggled item 6. Fresh 9999 bays
never got the prompt, leaving the bay stuck on placeholder values until
someone noticed.
New Register-CheckMachineNumberTask.ps1 auto-registers the logon task
at imaging time. Gated on C:\Enrollment\machine-number.txt == 9999;
bays imaged with a real number never get the task (and any stale task
from a prior 9999-imaging on the same disk is cleaned up).
Wired into Run-ShopfloorSetup.ps1 right after the S: drive logon mapper
register. Skipped for self-contained types (display kiosks have no
machine number).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Setup chains we do not control (FormTracePak Setup.exe, eDNC MSI, any
vendor installer that forces an immediate reboot) cut & $script off
mid-flight. Without this, the dispatcher never returns from the call
and the post-call Register-NextRun never fires, leaving the next boot
with no RunOnce + a stalled imaging chain. Observed today on WJF00159
where the FormTracePak v6.213 Setup.exe rebooted the bay before the
dispatcher could advance the stage.
Register the dispatcher's own RunOnce defensively before invoking the
sub-script. If a reboot interrupts the call, the next boot re-fires the
same dispatcher, which re-reads the still-'shopfloor-setup' stage file,
re-runs Run-ShopfloorSetup (every step is idempotent + detects already-
installed state), and converges. The existing post-call Register-NextRun
+ stage advance still run on the happy path - cheap, idempotent.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
