ge-aerospace/pxe-server
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Put the marker entries where the share actually looks

Browse Source 
Both entry files described the wrong scope. Checking the live share mirror:

Backup-PartMarker.ps1 belongs in common\scripts, not the partmarker scope,
because it imports ..\lib\TelesisMarker.psm1 and ..\lib\ShopdbBackupClient.psm1
and those live in common\lib. Backup-NtlarsSettings.ps1 sits there for the same
reason, and its entry already lists gea-shopfloor-partmarker in PCTypes -
scoping is by PCTypes, not by which directory the entry lives in. As written it
would have failed its imports on the first cycle.

eMxInfo healing is a NEW entry in the partmarker scope rather than a PCTypes
edit: those entries live in the collections and nocollections scopes, which a
marker bay never evaluates. The site already duplicates the config and the cmd
per scope, so markers follow that pattern - at the cost of the yearly rotation
now touching three copies, which the entry says out loud.

The cmd template also carried a stale source path. The deployed cmd reads
..\configs\eMxInfo.txt; the repo template still said the file sat beside it,
which would have exited 1 on every run.
This commit is contained in:
cproudlock
2026-08-25 14:01:26 -04:00
parent bd131f6da9
commit ba4df185cd
3 changed files with 24 additions and 23 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
playbook/shopfloor-setup/gea-shopfloor-partmarker/Install-eMxInfo-PartMarker.cmd.template
View File

@@ -19,7 +19,10 @@ REM Use this INSTEAD of Install-eMxInfo.cmd on gea-shopfloor-partmarker, or
REM simply add the marker PCType to the existing entry and accept that the Mark
REM copy goes stale - it is cosmetic either way.
set "SRC=%~dp0eMxInfo.txt"
rem The config lives in the scope's configs\ dir, NOT beside this file.
rem The repo copy of the collections template still says %~dp0eMxInfo.txt,
rem which is stale - the cmd actually deployed on the share uses ..\configs\.
set "SRC=%~dp0..\configs\eMxInfo.txt"
if not exist "%SRC%" (
echo Install-eMxInfo-PartMarker: source file not found at %SRC%
exit /b 1

20
playbook/shopfloor-setup/gea-shopfloor-partmarker/manifest-entry-emxinfo-partmarker.json
View File

@@ -1,12 +1,12 @@
{
"_comment": "eMxInfo.txt healing for MARKER bays. Today the eMxInfo entry on the share is scoped to gea-shopfloor-collections and gea-shopfloor-nocollections, so a marker bay never heals - and marker bays run eDNC too (01-eDNC.ps1 installs it before the Mark MSI), so they are clobbered by exactly the same vendor installer. THE FIX IS A SCOPING CHANGE, not a new entry: add \"gea-shopfloor-partmarker\" to the PCTypes array of the EXISTING eMxInfo.txt entry in the share manifest. This file records that change and why; it is not a second entry to add alongside the first.",
"_why_the_dnc_paths_are_the_right_target": "The Mark suite reads eMxInfo from the DNC install, not from its own directory: mxTransactionDll.dll references \\Dnc\\Server Files\\eMxInfo.txt (and eMxInfo.obs). So the two paths Install-eMxInfo.cmd already writes - C:\\Program Files\\DNC\\Server Files and C:\\Program Files (x86)\\DNC\\Server Files - are the ones that matter on a marker bay as well, and the existing cmd needs no change. 02-Setup-PartMarker.ps1 also drops a copy at C:\\Program Files (x86)\\Mark\\eMxInfo.txt at imaging time; nothing in the Mark binaries reads that path, so it is cosmetic. Install-eMxInfo-PartMarker.cmd.template refreshes it anyway, purely so a healed bay is byte-identical to a freshly imaged one and nobody has to wonder why they differ.",
"_detection": "Unchanged: DetectionMethod Hash against the x86 DNC path, DetectionValue is the SHA256 of the current site file. Ordering still matters - the eDNC entry must be evaluated BEFORE this one, so a fresh install clobbers the file and the hash check then restores it in the same cycle. On a marker bay the Mark MSI is a second clobber risk, and the same ordering rule covers it.",
"PCTypes_change": {
"from": ["gea-shopfloor-collections", "gea-shopfloor-nocollections"],
"to": ["gea-shopfloor-collections", "gea-shopfloor-nocollections", "gea-shopfloor-partmarker"]
}
"_comment": "CORRECTED 2026-08-25. The eMxInfo entries live in the COLLECTIONS and NOCOLLECTIONS scopes, which a marker bay never evaluates - so this is a new entry in gea-shopfloor-partmarker/manifest.json, not a PCTypes edit to an existing one. The site already duplicates this per scope: each carries its own configs/eMxInfo.txt and scripts/Install-eMxInfo.cmd. Markers now do too.",
"_files": "gea-shopfloor-partmarker\\configs\\eMxInfo.txt (copied from the collections scope - site secret, never committed) and gea-shopfloor-partmarker\\scripts\\Install-eMxInfo.cmd (the variant that also refreshes the copy imaging leaves in C:\\Program Files (x86)\\Mark).",
"_ordering": "None needed inside this scope: no eDNC installer entry reaches markers through GE-Enforce, so there is nothing to be evaluated after. Hash detection fires whenever the file is missing or stale, which is what a hand reinstall of eDNC or Mark produces.",
"_rotation": "Yearly rotation of eMxInfo.txt now touches THREE scopes - collections, nocollections and partmarker. Overwrite configs/eMxInfo.txt in each, recompute the SHA256, paste it into each DetectionValue.",
"Name": "eMxInfo.txt",
"Installer": "scripts/Install-eMxInfo.cmd",
"Type": "CMD",
"DetectionMethod": "Hash",
"DetectionPath": "C:\\Program Files (x86)\\DNC\\Server Files\\eMxInfo.txt",
"DetectionValue": "87733201CB11E7343BD432F1E303FBF41DB58EBAAEFF37BD4C3C9B267B145A20"
}

22
playbook/shopfloor-setup/gea-shopfloor-partmarker/manifest-entry-partmarker-backup.json
View File

@@ -1,15 +1,13 @@
{
"_comment": "Drop this entry into the SFLD share's gea-shopfloor-partmarker manifest.json (Applications array). Type=PS1 + DetectionMethod=Always means GE-Enforce runs it straight off the share every cycle under SYSTEM, with no local copy - so updating the script on the share changes fleet behaviour on the next cycle and there is nothing to heal locally. PCTypes scopes it to marker bays; the script also checks the DNC\\Mark registry itself and exits quietly on a PC that drives no marker, so a mis-scoped entry is harmless rather than noisy.",
"_layout": "REQUIRES THREE FILES ON THE SHARE, and the script resolves its modules relative to its own location ($PSScriptRoot\\..\\lib\\): scripts\\Backup-PartMarker.ps1, lib\\TelesisMarker.psm1, lib\\ShopdbBackupClient.psm1. ShopdbBackupClient is SHARED with Backup-NtlarsSettings.ps1 and is UPDATED by this work (it gained manifest posting, the created-vs-noop reader and skipped-cycle accounting), so deploy the new copy - the NTLARS backup uses none of the additions and is unaffected. If the share puts scripts in apps\\ rather than scripts\\, the lib\\ directory must be its sibling or the imports fail.",
"_schedule": "Captures run ONLY at shift changes - 14:00 normally, because someone is on site then to fix a problem; 06:00 and 22:00 engage only once the backup is 3+ days overdue. Outside those hours the script exits without touching the port. The marker's COM port is shared with eDNC and is exclusive-open, so a capture at a random hour would fail an operator's mark. The capture also yields the port within about a second if the marker application starts mid-run, and ShopDB's backups_intervalhours throttle still applies on top.",
"_settings": "ShopDB must have backups_shareroot set, and the bay needs a collector key in HKLM\\SOFTWARE\\GE\\ShopDB\\CollectorKey (or C:\\Enrollment\\shopdb-key.txt) plus a machine number in C:\\Enrollment\\pc-config.txt. Missing any of these is logged once and the cycle skips - it does not error.",
"Name": "Back up the Telesis part marker (patterns, fonts, settings) to ShopDB",
"PCTypes": ["gea-shopfloor-partmarker"],
"Script": "scripts/Backup-PartMarker.ps1",
"_comment": "CORRECTED 2026-08-25 after checking the live share layout. This entry goes in common/manifest.json, NOT the partmarker scope: the script imports ..\\lib\\TelesisMarker.psm1 and ..\\lib\\ShopdbBackupClient.psm1, and those live in common\\lib. Backup-NtlarsSettings.ps1 sits in common for the same reason, and its entry already carries a PCTypes list including gea-shopfloor-partmarker. Scoping is by PCTypes, not by which directory the entry lives in.",
"_files": "common\\lib\\TelesisMarker.psm1 (new), common\\lib\\ShopdbBackupClient.psm1 (UPDATED - shared with the NTLARS backup, which uses none of the additions), common\\scripts\\Backup-PartMarker.ps1 (new). Test-ShareAccess.ps1 also goes in common\\scripts but needs no manifest entry: it is a hand-run diagnostic.",
"_schedule": "Captures run only at shift changes - 14:00 normally because someone is on site to fix a problem, 06:00 and 22:00 only once the backup is 3+ days overdue. The marker's COM port is shared with eDNC and exclusive-open, so a capture at a random hour would fail an operator's mark.",
"_settings": "ShopDB needs backups_shareroot set, and the bay needs a collector key plus either a machine number in pc-config.txt or a device asset number in C:\\Enrollment\\asset-id.txt. Missing any of these is logged once and the cycle skips.",
"Name": "Part Marker Backup to ShopDB",
"Type": "PS1",
"DetectionMethod": "Always"
"Script": "scripts/Backup-PartMarker.ps1",
"DetectionMethod": "Always",
"PCTypes": [
"gea-shopfloor-partmarker"
]
}