From c73b53f613777098fd963b7d39756a28610725da Mon Sep 17 00:00:00 2001 From: cproudlock Date: Thu, 20 Aug 2026 10:51:39 -0400 Subject: [PATCH] Make phase 3 a correctness fix, not a tidy-up Phase 3 was written as "the collector reads a registry value". It is all three components moving together: imaging writes DeviceId, GE-Enforce resolves device identity registry-first, and the collector reads the registry ahead of the file. The argument for it is already in the fleet's own code. Install-FromManifest resolves TargetMachineNumbers gating from the eDNC registry BEFORE machine-number.txt, and says why: the file is written ONCE by startnet.cmd at the PXE menu and is not updated on reassignment, so it goes stale. asset-id.txt inherits that defect exactly. Nothing rewrites it when a device is swapped, moved between bays or replaced, and phase 1 put it at the TOP of the resolution order - so a stale value is adopted with no warning, because it still resolves. A file only imaging writes cannot be the top of a resolution order for something that changes during a PC's life. Also records the consequence: phase 3 needs a reassignment path the way Set-MachineNumber exists for the bay number, or it moves the staleness from a file into a registry value instead of curing it. --- docs/proposals/device-identity.md | 34 +++++++++++++++++++++++++++++++ 1 file changed, 34 insertions(+) diff --git a/docs/proposals/device-identity.md b/docs/proposals/device-identity.md index e97de87..907349d 100644 --- a/docs/proposals/device-identity.md +++ b/docs/proposals/device-identity.md @@ -148,6 +148,40 @@ first, each when no bay has reported through it for a full inventory cycle. **`cmmid.txt` survives phase 3 regardless**, as the CMM backup-set path key. It is not on the deletion list; only its identity use is. +### PXE and GE-Enforce prefer it too, not just the collector + +Phase 3 is not only "the collector reads a registry value". All three writers +and readers move together: + +| Component | Change | +|---|---| +| PXE / imaging | writes `DeviceId` at enrollment instead of (or as well as) the file | +| GE-Enforce | resolves device identity registry-first, mirroring how it already resolves the machine number | +| collector | reads the registry ahead of the file | + +**GE-Enforce already made this exact decision for the machine number, and wrote +down why.** `Install-FromManifest.ps1` resolves `TargetMachineNumbers` gating +from the eDNC registry BEFORE `C:\Enrollment\machine-number.txt`, because: + +> the imaging-time `machine-number.txt` is written ONCE by `startnet.cmd` at the +> PXE menu and is NOT updated on reassignment, so it goes stale. + +**`asset-id.txt` inherits that defect exactly.** It is written once at imaging +and nothing updates it when a device is swapped, moved between bays, or +replaced. The bay then reports an identity that was true on imaging day, and the +collector - which now trusts that value FIRST, ahead of every other source - +adopts the wrong device with no warning, because the value still resolves. + +That makes phase 3 a correctness fix rather than a tidy-up. A file that only +imaging writes cannot be the top of a resolution order for something that +changes during a PC's life. + +It also implies a reassignment path, the way `Set-MachineNumber` / +`Update-MachineNumber` exist for the bay number: something that rewrites +`DeviceId` when a device is swapped, and migrates any per-device state with it. +Without that, phase 3 moves the staleness from a file to a registry value rather +than curing it. + ### Doing phase 3 early is cheaper than doing it late If the registry read lands before imaging is changed, phase 2 can write the