docs: EventSaver, and how GE-Enforce reaches a bay in the first place
EventSaver was undocumented anywhere a reader could find it. What it is, the two source modes and why HTTP is the one to use, how order.txt and the ShopDB feed each decide the running order, the three command-line switches Windows calls it with, where it must NOT run (a screensaver over a live dashboard or a metrology run is a defect), how to build it with the in-box compiler, and a table of symptoms with the first thing to check. The adoption guide also stopped short of the question it invites: the fleet tools assume GE-Enforce is already on the PC, so how does GE-Enforce get there. Both real paths are now written down - imaging time, which is how the shop-floor pipeline does it, and Intune, which is how the display cohort is deployed today because those PCs are Entra-joined with no share. Machine Configuration is possible and unshipped, with the caveat that matters: DSC and GE-Enforce are both convergence loops, so give each a layer to own rather than pointing them at the same configuration.
This commit is contained in:
@@ -351,6 +351,69 @@ been uploaded for that surface, not that the PC is misconfigured.
|
||||
|
||||
---
|
||||
|
||||
---
|
||||
|
||||
## Part 3: bootstrapping GE-Enforce itself
|
||||
|
||||
The two parts above assume the tools are already on the PC. GE-Enforce is what
|
||||
puts them there and keeps them there - so the question is how GE-Enforce gets
|
||||
onto a bay in the first place. Two paths are supported, and they are the two
|
||||
that actually occur: imaging time, and a management plane such as Intune.
|
||||
|
||||
Whichever you use, the end state is the same three things:
|
||||
|
||||
1. The client files in `C:\Program Files\GE\Shopfloor`.
|
||||
2. `HKLM:\SOFTWARE\GE\ShopDB` carrying `BaseUrl`, and `ApiToken` where the scope
|
||||
is served over HTTPS.
|
||||
3. A scheduled task running the enforce cycle as SYSTEM.
|
||||
|
||||
### At imaging time (the usual path)
|
||||
|
||||
The shop-floor imaging pipeline registers the enforce task as its last step,
|
||||
once the PC type is known - the type is what decides which manifest scope the
|
||||
bay enforces. Self-contained types are skipped deliberately: a display kiosk
|
||||
gets its configuration at imaging time and no share, so registering an enforce
|
||||
task on one would give it a cycle with nothing to do.
|
||||
|
||||
If you are building your own imaging pipeline, the equivalent step is: copy the
|
||||
engine into a runtime directory, write the PC type where the client can read it,
|
||||
and register the task. That is what `Install-GEEnforce.ps1` does in one call.
|
||||
|
||||
### Through Intune
|
||||
|
||||
`Install-GEEnforce.ps1` is parameterised for exactly this, and this is how the
|
||||
display cohort is deployed today - those PCs are Entra-joined, have no file
|
||||
share, and fetch their manifest over HTTPS:
|
||||
|
||||
```powershell
|
||||
.\Install-GEEnforce.ps1 `
|
||||
-PCType 'gea-shopfloor-common' `
|
||||
-ShopdbUrl 'https://shopdb.example.net' `
|
||||
-ShopdbToken 'shopdb_pat_REPLACE_WITH_YOUR_TOKEN'
|
||||
```
|
||||
|
||||
Package it as a Win32 app with the client files. Detection rule: the scheduled
|
||||
task exists **and** `HKLM:\SOFTWARE\GE\ShopDB\BaseUrl` matches your server, so a
|
||||
PC that was imaged for another site is repaired rather than skipped.
|
||||
|
||||
The token is a managed service token scoped to the GE-Enforce fetch scope, not
|
||||
an admin credential. Scope it that way and a token read off a bay buys the
|
||||
reader a manifest they could have read anyway.
|
||||
|
||||
### With DSC (Machine Configuration)
|
||||
|
||||
There is no shipped DSC configuration, but nothing about the end state resists
|
||||
one - it is two registry values, a set of files and a scheduled task, which is
|
||||
ordinary DSC territory. Express it the same way as the reporter example above:
|
||||
`Registry` resources for `BaseUrl` and `ApiToken`, `File` resources for the
|
||||
client, and a `Script` resource that registers the task.
|
||||
|
||||
One caution. DSC converges state on a schedule and GE-Enforce is itself a
|
||||
convergence loop, so running both against the same PC means two things fighting
|
||||
to own the same configuration. Use DSC to install and configure the client, and
|
||||
let GE-Enforce own everything downstream of that. Deciding which tool owns what
|
||||
is the whole job; splitting it by layer is what keeps it answerable.
|
||||
|
||||
## Which path to choose
|
||||
|
||||
| You have | Use |
|
||||
|
||||
Reference in New Issue
Block a user