One installer, many configurations

Why the MSI is not built per customer

It would be easy to generate a per-tenant installer: compile the licence and the branding

into it, hand each customer their own .msi, and have nothing to explain. That is the

wrong trade, for three reasons.

Signatures. A per-tenant installer is a per-tenant binary. Every one needs its own

Authenticode signature, every signing run is an opportunity to ship an unsigned or

wrongly-signed artifact, and there is no single hash anybody can check. With one installer

there is exactly one digest, it is published in the dashboard and in the release feed, and

an administrator can verify what they downloaded with Get-FileHash before they put it on

three hundred machines.

Auditability. "Which installer is in production?" has one answer. A security review can

examine one binary. A malware report about one customer's file is a report about everyone's

file, which is a feature: it gets investigated.

Rebuild cost. A licence changes when a seat count changes. If the licence were compiled

in, every seat change would mean a new installer, a new signature, and a redeployment.

Instead a seat change means re-downloading a 4 KB bundle.

What is in the bundle

Downloaded from the Deployment page as endpointtrust-<slug>-config.zip.

Neither trust.json nor license.jws is a secret — one holds a public key, the other is

signed configuration. Both are integrity-critical: change a byte of the licence and

every computer rejects it, because the signature no longer verifies under the key in

trust.json.

The endpoint reads both from the install directory, under the same restrictive DACL as the

rest of its state, so an ordinary user cannot replace them.

What is deliberately NOT in the bundle

The enrollment credential. It is the one secret in a deployment: it authorises a machine

to register itself with the organisation, consume a seat, and receive the policy. A bundle

gets copied to a file share, and a secret on a file share is a standing secret in a readable

place.

So it is issued separately, shown exactly once, and placed on each machine as its own file

which etadmin activate --credential-file reads, overwrites and deletes. EndpointTrust stores

only its SHA-256 and a six-character hint, which is why the console cannot show you one

again.

Branding: what is actually branded

Be precise about this, because a customer who uploads a logo and does not see it has been

misled.

• The display name appears in every SMS. Acme Ltd: your sign-in code is 123456. This

is the branding that people actually see, and it is real.

• The logo appears in the dashboard and travels in the bundle.
• The logo does not appear on the Windows credential tile. Showing it there needs a

CPFT_TILE_IMAGE field which the credential provider does not implement yet. The file is

carried in the bundle so that adding it becomes a change to the endpoint alone.

• The installer is not branded. See above.

SVG logos are refused. An SVG is a document that can carry script and external references,

and it would be rendered in an administrator's browser next to live tenant data.

Upgrades

EndpointTrust publishes a version; it does not install one. There is no auto-update service, no

background task and no self-replacing binary in the agent — those were removed from the

endpoint deliberately, and adding them back from the server side would reintroduce exactly

what was removed.

An upgrade is the same Group Policy deployment with a newer MSI. agent_releases carries a

min_upgradable_from: below it, an in-place upgrade is not supported and the dashboard says

"reinstall required" rather than offering an upgrade that fails halfway.