Installing the agent across a domain

The dashboard shows a short version of this on the Deployment page. This is the long one.

What you need

1. The MSI, and its published SHA-256.
2. Your configuration bundle: trust.json and license.jws.
3. One enrollment credential.

1. Verify the installer

Get-FileHash .\endpointtrust-agent.msi -Algorithm SHA256

Compare it with the digest on the Deployment page. This is the step that makes the download

host untrusted rather than trusted, and it is the step everybody skips.

2. Stage the files

\\dc01\Deploy\EndpointTrust\
    endpointtrust-agent.msi
    trust.json
    license.jws

Share and NTFS permissions: read for Domain Computers, write for your administrators

and nobody else. The computers install as SYSTEM, so the computer accounts need the read

right, not the users.

Neither trust.json nor license.jws is a secret. Both are integrity-critical: if somebody

who can write to this share replaces trust.json, they control which keys the endpoint

trusts. Lock down the write side.

3. Assign the package

Group Policy Management → new GPO linked to the OU containing the computers →

Computer Configuration
  → Policies
    → Software Settings
      → Software installation
        → New → Package…  →  \\dc01\Deploy\EndpointTrust\endpointtrust-agent.msi
        → Assigned

Use the UNC path, not a drive letter: the computer account resolves it, and a mapped

drive does not exist at boot.

Assigned, not Published. Assigned installs at boot, before anybody signs in, which is

what you want for something that participates in the logon screen. Published would wait for

a user action that never comes on a workstation.

4. Activate each machine once

Activation is separate from installation because it needs the enrollment credential, and

the credential must never appear on a command line, in an MSI log, or in Group Policy

preferences (which are readable by any authenticated user — that is a well known mistake

and this avoids repeating it).

Issue a credential on the Deployment page, then place it as a file and run:

etadmin.exe activate --credential-file C:\Windows\Temp\endpointtrust-enroll.txt

etadmin reads the file, overwrites it, and deletes it. A startup script is the usual

carrier:

Computer Configuration → Policies → Windows Settings → Scripts → Startup

Deliver the credential file by whatever mechanism your organisation already trusts for

short-lived setup material. Do not put the value in a Group Policy preference, an

environment variable, or a script you commit.

5. Reboot

Group Policy software installation applies at boot, by design. There is no agent here that

reboots a machine for you — that was removed deliberately, along with the rest of the

background-service surface.

6. Watch the console

The Computers page fills in as machines activate.

A machine that activates more than once shows an activation count above 1. That usually

means an image was cloned, or a machine was rebuilt without being purged first. Each

activation issues a new credential and the previous one stops working.

Upgrading

Same process, newer MSI, as an upgrade package in the same GPO (Group Policy's own

"Upgrade" relationship on the software installation entry). Activation does not need to run

again: the device keeps its registration and its credential.

Check the Deployment page for min_upgradable_from. Below it, do a clean uninstall and

install rather than an upgrade — an upgrade path that silently does not work is worse than

one that refuses.

Uninstalling

etadmin.exe uninstall-credential
etadmin.exe purge

then remove the package from the GPO. etadmin unregisters the credential provider filter

first, which is the ordering that matters: a filter left registered with no provider

behind it is how a machine ends up with no usable logon tiles.

If something goes wrong at a logon screen

The recovery path is documented in the endpoint repository's docs/installation.md. The

summary: boot to Safe Mode, which does not load third-party credential providers, and run

etadmin.exe disarm.