Workstation installation

One MSI, one msiexec line, and a bare machine is waiting in the admission queue. The package TrustBridge-Workstation-<version>-x64.msi carries both workstation components, the Workstation Service and the Tray App, published self-contained, so a machine with no .NET runtime needs nothing installed first. Beside it Lacuna Software provides TrustBridge-Workstation-GroupPolicy-<version>.zip with the Group Policy templates. The current release is Workstation 1.10.0.

This page is what an operator types. Workstation configuration is what each value may say: every setting the service takes, its default and what a bad one does.

Before you start

• A 64-bit Windows machine and administrative rights on it. The package is per-machine, x64 only, and needs Windows Installer 5.0 (Windows 7 and later). ARM64 is not supported.
• Nothing else installed. Both components are self-contained, which is what makes the package about 100 MB.
• The Server's URL, reachable from the machine. The one value the install refuses to proceed without.
• A Server that speaks this release's protocol. Workstation 1.10.0 speaks protocol 6, which Server 1.15.0 and later accept, but deliver it with Server 1.20.0 or later, the first that takes its Workstation Report, and with Server 1.23.0 or later to see the console it reports. An older Server refuses the machine at the handshake; see Which Server a release needs.
• Nothing for the PKI licence. A machine gets its licence from its Server, in the handshake, once it is admitted, and nothing on the msiexec line can supply one. The Server carries it as its own Certificates:Validation:License. Until the machine is admitted and connected, every certificate on it reads UNTRUSTED.
• An Administrator who will admit the machine. Installing does not join the fleet; a person does, on the Server.
• A TLS chain the machine trusts. The Workstation Service refuses an untrusted Server certificate, and the symptom is a machine that never appears in the queue.
• The signed package. Releases are Authenticode-signed; check the package before you deploy it (next section).

The signature

A release package is Authenticode-signed, and so is every TrustBridge assembly inside it. The signer is Lacuna Software's code-signing certificate, subject LACUNA SOFTWARE LTDA, issued by Sectigo, and every signature carries an RFC 3161 timestamp, so a package keeps validating after the certificate it was signed with expires. Windows shows the publisher as LACUNA SOFTWARE LTDA on the elevation prompt; Programs and Features lists the product under Lacuna Software. The .NET runtime files beside the product's own are Microsoft's and carry Microsoft's signature.

Releases are signed from 1.2.1 on. 1.2.1 itself was withdrawn the day it shipped (it could not upgrade a 1.2.0 machine), so the first signed release to deploy is 1.2.2.

Check a package before you deploy it. The first line needs the Windows SDK's signtool, which is not on PATH by default; the second needs nothing:

signtool verify /pa /v TrustBridge-Workstation-1.10.0-x64.msi

Get-AuthenticodeSignature TrustBridge-Workstation-1.10.0-x64.msi | Format-List Status, SignerCertificate, TimeStamperCertificate

A release package answers Successfully verified to the first, with The signature is timestamped above it, and Valid to the second with a TimeStamperCertificate filled in. The installed executables answer the same way (C:\Program Files\TrustBridge\Workstation Service\TrustBridge.WorkstationService.exe and C:\Program Files\TrustBridge\Tray App\TrustBridge.TrayApp.exe), which is how to tell, on a machine, whether what is running is a release.

An unsigned package is never a release. A SmartScreen hold, an Unknown publisher on the elevation prompt, or a package that a publisher-requiring GPO or Intune posture refuses means you are holding something other than the package Lacuna Software released: use the release package instead.

The one line

msiexec /i TrustBridge-Workstation-1.10.0-x64.msi /qn SERVER_URL=https://trustbridge.example.com

That is a complete fleet install. In order, it:

1. Checks SERVER_URL and fails the whole transaction if it is empty or not scheme-prefixed.
2. Lays both components under C:\Program Files\TrustBridge\, creates the machine-state tree under C:\ProgramData\TrustBridge\ with a DACL admitting only Administrators and LocalSystem, and registers the Tray App's autostart entry and its Start menu shortcut.
3. Writes the install-time configuration to HKLM\Software\TrustBridge.
4. Registers TrustBridge Workstation Service with the SCM (LocalSystem, automatic start, restart-on-failure) and starts it, waiting for the start to succeed.
5. The service mints its Workstation Key in the machine's TPM (falling back to the software provider), announces itself to the Server, and stands Pending in the admission queue. It also starts the Tray App in every session somebody is signed into.

The install's last act is the service coming up. A service that refuses to start (an INSTALLER_KEY that is not a key, a registry value of the wrong type) fails the install and rolls it back, rather than leaving a machine that looks installed and never connects.

msiexec does not wait. It returns immediately, and the next line of a deployment script runs while the install is still going. To read the outcome, wait for the process:

$install = Start-Process msiexec -Wait -PassThru -ArgumentList @(
    '/i', 'TrustBridge-Workstation-1.10.0-x64.msi',
    '/qn',
    '/l*v', 'C:\Windows\Temp\trustbridge-install.log',
    'SERVER_URL=https://trustbridge.example.com'
)
$install.ExitCode

Exit codes are Windows Installer's own: 0 succeeded, 1602 cancelled, 3010 succeeded and something wants a reboot, 1603 fatal error, which is what both of this package's own refusals surface as. The reason is a line in the /l*v log; search it for SERVER_URL or newer version.

The five properties

Every value an msiexec line may set. Each is written to HKLM\Software\TrustBridge as a registry value rather than into a settings file, which is what makes them survive an upgrade with no remember-the-property machinery.

Property	Registry value	Configuration key
SERVER_URL	ServerUrl	Server:Url	Required. Gated by the launch condition.
INSTALLER_KEY	InstallerKey	Server:InstallerKey	Optional. Most deployments never pass it.
INSERTION_PROMPT	InsertionPrompt	Tray:InsertionPrompt	Optional. 0 turns the Insertion Prompt off, 1 on. Unset is on at a first install and the machine's own value on an upgrade or repair.
RESTART_FAILED_READERS	RestartFailedReaders	Certificates:RestartFailedReaders	Optional. 0 turns off the restart of a smart-card reader Windows could not start, 1 on. Unset as above.
WORKSTATION_REPORT	WorkstationReport	WorkstationReport:Enabled	Optional. 0 turns the Workstation Report off, 1 on. Unset as above.

There is no licence property. Workstation 1.0 took one, PKI_LICENSE; it was removed in 1.1.0, when the Server became the machine's only licence source. A line that still passes it installs, and nothing reads the value.

INSTALLER_KEY is for a deployment that minted an Installer Key of its own and configured its public half on the Server under Admission:InstallerKeys. Left unset, no value is written and the product's own key applies. It is not a secret and admits nothing on its own.

INSERTION_PROMPT=0 keeps the token balloon. By default a token inserted at an unlocked console opens a window asking for its PIN, so the signatures that follow need no prompt: the Insertion Prompt (Workstation 1.7.0). A desktop where that window is unwelcome passes 0, and the Tray App announces the token in a notification instead, as it did before the window existed. Left unset on a first install, no value is written and the window is on; left unset on an upgrade or repair, the machine keeps the value it already holds, so one installed with 0 stays off until INSERTION_PROMPT=1 is passed.

RESTART_FAILED_READERS=0 keeps TrustBridge out of device state. By default, when Windows fails to start a USB smart-card reader, often a token's own (problem code 10 in Device Manager), the Workstation Service restarts that reader up to three times per plugging-in, on a machine that looks for A3 tokens, and never restarts the machine (Workstation 1.8.0). An estate whose policy forbids software changing device state passes 0, and the Tray App tells the holder at once to unplug the reader (for a USB token, the token itself) and plug it back in.

WORKSTATION_REPORT=0 keeps a machine's condition on the machine. By default the Workstation Service tells its Server about its own condition (its PKI licence and runtime, its switches, its tokens and readers, its token middleware, the errors it logged and, from Workstation 1.10.0, the Windows account signed in at its console), which the Server's fleet screen shows to support (Workstation 1.8.0, Server 1.20.0). An estate that wants none of it to leave the machine passes 0: the machine then tells its Server only that reporting is off, the Server forgets what it reported before, and the fleet screen shows it as Not reported. The Console Account stays on the machine with the rest.

The last two behave as INSERTION_PROMPT does when unset. For all three, a value other than 0 or 1 does not fail the install: the service reads it as off and names it at Error in its start-up log. A Group Policy beats each of them (below).

None should need quoting. A URL has no spaces, and the key is base64 on one line.

The launch condition

SERVER_URL must be present and begin http:// or https://, or the transaction fails before anything is written. Silent and interactive alike; install, upgrade and repair alike, though an upgrade and a repair satisfy it from the machine's own value without you passing anything. The one transaction it does not gate is removal. A service refusing at start would be a machine crash-looping, discovered when somebody cannot sign; a refused install is one loud failure while somebody is watching.

The release package carries no default Server URL. A build made for a particular deployment can carry one, so its fleet line becomes msiexec /i <msi> /qn and the interactive field arrives pre-filled. A value on the line still wins, and so does the value a machine already holds.

What an install puts on the machine

C:\Program Files\TrustBridge\Workstation Service\	The service and its self-contained runtime
C:\Program Files\TrustBridge\Tray App\	The Tray App and its own
C:\ProgramData\TrustBridge\	Machine state: the PIN Cache, its key ring, the cached Trusted CA set, the A1 PINs, and the version that last started, which is how the service tells an upgrade from a restart. Administrators and LocalSystem only
C:\ProgramData\TrustBridge\anchors\	Where trust anchor files go, same DACL
C:\ProgramData\TrustBridge\updates\	Created when the machine first takes an update from its Server: the downloaded package, the record of the last Server-delivered update and its install logs. SYSTEM and Administrators only
HKLM\Software\TrustBridge	The install-time values above that the line, or the machine before it, supplied
HKLM\…\CurrentVersion\Run → TrustBridge Tray App	Machine-wide autostart, so the Tray runs for every interactive user. Its command line ends in --background (Workstation 1.9.0), which starts the Tray as an icon with no window
Start menu → TrustBridge	One shortcut for every user, in the all-users Programs folder (Workstation 1.9.0). It opens the Tray App's window
Service TrustBridge Workstation Service	LocalSystem, automatic, restarts three times on failure at one-minute intervals
Application event source TrustBridge Workstation Service	Where a refusal before logging exists, and an uninstall's purge report, is written

The install directory is fixed. The Workstation Key is not in this table because the service mints it into a CNG container the first time it starts, and nothing but the service's own purge verb can remove it.

The service starts the Tray App in every session somebody is signed into, once, on its first start after an install or an upgrade. It runs the autostart entry's own command line, --background included, as each session's user, so the icon arrives without anybody signing out and in again; later sign-ins get it from the autostart entry as usual. A session where Windows refuses the start is named in the service's log. Until the Tray App is running in a session there is nobody there to answer a PIN prompt.

A holder reopens the Tray App from the Start menu's TrustBridge shortcut (Workstation 1.9.0). With no Tray in the session, it starts one and opens its window. With one running, it brings that Tray's window forward and starts nothing beside it. A Tray that does not answer within 5 s is ended and replaced by one with its window open, and the new Tray logs that at Error, which reaches the Workstation Report where the report is on. A Tray that cannot be ended is left running, and the shortcut says so in a message (The Tray App is already running in your Windows session, but it is not responding and could not be closed.), with nothing in the report: signing out of Windows and back in is then the way back. Only that user's own session is touched. Running Tray App\TrustBridge.TrayApp.exe does the same. The autostart's --background is what makes a sign-in show only the icon, and leave a Tray that answers as it was.

Installing interactively

Double-clicking the MSI gives one screen of this package's own inside the stock progress and finish screens: on a bare machine, a single Server URL field over the same SERVER_URL property; on a machine that already has the package, a repair, re-point or remove screen with the field pre-filled. There is no EULA, no directory chooser and no feature tree. The dialogs are English only, deliberately: they are deployment tooling for the operator. The Tray App a user sees speaks the user's language.

The Installer Key and the three switches have no field. Give them to a single interactive machine by a silent repair line.

Admitting the machine

Installing does not join the fleet. The machine announces itself and waits, Pending, until an Administrator makes it Admitted on the admission queue at /admin/admission. Until then the service is running, reaching the Server, and connecting to nothing; its log says why at each reconnect, and the Tray App says Admission pending.

What admitting means is bounded, and the screen says so: with no out-of-band channel to check a fingerprint against, admitting is a rate-limited human gate over a queue. A machine is noticed rather than verified. What makes that acceptable is that it is not optional; nothing a machine holds admits it on its own. Read the machine's hostname, operating system, versions and key posture (hardware or software) before admitting it.

Once admitted, the machine connects on its next reconnect attempt, is handed its PKI licence, and appears on the fleet screen at /admin/fleet. A machine sent back to Pending keeps its key and its history; a machine Revoked is refused for as long as its row stands, and has no way back except as a new machine: with a new key, or with the same one after an Administrator Removes it, which takes the refusal with the row (Server 1.21.0).

An abandoned Pending request lapses after Admission:PendingExpiry (7 days by default, counted from the machine's last request) and its row is deleted. That is not a refusal; the machine simply asks again as one the platform has never seen. Only a machine no Administrator has ever admitted can lapse. A machine sent back to Pending waits until somebody rules on it: by admitting it again, or by Remove on its row of the queue, behind the same typed hostname as on the fleet screen.

If the machine never appears in the queue

Read the service's own account first: the Windows Application log, source TrustBridge Workstation Service, and the service's log. Four things cause a refused admission request, and the Server deliberately does not say which, so the machine's log names all four: the machine was revoked; its Installer Key is one this Server does not trust; too many requests came from its address; or the queue is full. The last two clear themselves.

The service says where each of its install-time values came from, at every start, one line per value in the form Server:Url is https://…, supplied by …. The Installer Key gets the same line with set or not set in place of the value, and so does the licence, which on a machine configured only by the MSI reads not set: the Server supplies it once the machine is admitted and connected. Read those lines before touching the registry.

sc.exe query "TrustBridge Workstation Service"
Get-ItemProperty 'HKLM:\Software\TrustBridge'
Get-ItemProperty 'HKLM:\Software\Policies\TrustBridge' -ErrorAction SilentlyContinue

Run those from a 64-bit PowerShell. The preference lives in the 64-bit registry view; a 32-bit host is redirected to WOW6432Node, where a perfectly configured machine looks bare.

Two locations, because the second one wins: a Group Policy value at HKLM\Software\Policies\TrustBridge beats what the installer wrote, and a machine pointing at the wrong Server is usually a machine in a GPO's scope somebody forgot about. Both are read once, at start.

A machine whose version is newer than its Server's protocol window never gets as far as the queue being useful: the Server refuses its handshake with update the Server first, and the service logs that verdict. See Which Server a release needs.

Group Policy: deploying the templates

The ADMX template lets a domain set five values across a fleet: the Server URL (Server:Url), whether machines take updates from their Server (ServerUpdates:Enabled), whether a token going in opens the Insertion Prompt (Tray:InsertionPrompt), whether the service restarts a smart-card reader Windows could not start (Certificates:RestartFailedReaders), and whether machines report their condition to their Server (WorkstationReport:Enabled). It is never installed by the MSI: nothing the package writes may live under \Policies, because policy processing deletes the values it stops managing. Unzipped, the release's template archive is three files:

admx\TrustBridge.admx
admx\en-US\TrustBridge.adml
admx\pt-BR\TrustBridge.adml

Copy them into the domain's central store, language folders included:

$store = "\\$env:USERDNSDOMAIN\SYSVOL\$env:USERDNSDOMAIN\Policies\PolicyDefinitions"
New-Item -ItemType Directory -Force -Path $store, "$store\en-US", "$store\pt-BR" | Out-Null
Copy-Item admx\TrustBridge.admx $store
Copy-Item admx\en-US\TrustBridge.adml "$store\en-US"
Copy-Item admx\pt-BR\TrustBridge.adml "$store\pt-BR"

The New-Item line is not ceremony: Copy-Item to a folder that does not exist creates a file with that name, and a store in that state is broken in a way nothing complains about. A machine with no central store takes the same three files under %SystemRoot%\PolicyDefinitions. Either way the settings appear under Computer Configuration → Administrative Templates → TrustBridge Workstation:

Policy	Registry value under HKLM\Software\Policies\TrustBridge	Configuration key
Server URL	ServerUrl, a string	Server:Url
Take updates from the TrustBridge Server	ServerUpdates, a REG_DWORD	ServerUpdates:Enabled
Ask for a token's PIN when it is inserted	InsertionPrompt, a REG_DWORD	Tray:InsertionPrompt
Restart a smart-card reader Windows could not start	RestartFailedReaders, a REG_DWORD	Certificates:RestartFailedReaders
Report this machine's condition to the TrustBridge Server	WorkstationReport, a REG_DWORD	WorkstationReport:Enabled

Each REG_DWORD policy writes 1 when enabled and 0 when disabled.

Copy both languages even if your administrators read English. gpedit falls back per file rather than per string, so a store missing pt-BR\TrustBridge.adml costs a Brazilian console the whole template.

A policy change is a service restart, not a Group Policy refresh. The service reads both registry locations once, at start. gpupdate /force delivers the value, and the machine picks it up at the next start of the service:

Restart-Service "TrustBridge Workstation Service"

Server-delivered updates are on unless the policy says otherwise. Take updates from the TrustBridge Server writes HKLM\Software\Policies\TrustBridge\ServerUpdates, a REG_DWORD: 0 when the policy is disabled, which turns the channel off, and 1 when it is enabled. Not configured is on. Anything else there, such as a Preferences item that writes the value as a string, reads as off, and the service's start-up log says so at Error. There is no MSI property for it, so a GPO is the only way to turn it off on a fleet. A machine with it off tells its Server so, the Server offers it nothing, and the Workstations screen reads it as Updates disabled by policy.

The three switches are the installer's choice unless the policy says otherwise. Each of Ask for a token's PIN when it is inserted, Restart a smart-card reader Windows could not start and Report this machine's condition to the TrustBridge Server beats what the matching MSI property wrote, enabled or disabled:

• Insertion Prompt. Disabled keeps the token balloon; enabled opens the window whatever INSERTION_PROMPT the machine was installed with.
• Failed-reader restart. Disabled leaves the holder to unplug and replug; enabled restarts the reader whatever RESTART_FAILED_READERS the machine was installed with.
• Workstation Report. Disabled has the machine report only that reporting is off; enabled reports in full whatever WORKSTATION_REPORT the machine was installed with.

Not configured leaves the machine to the value the installer wrote, and to on where it wrote none. Anything there but 0 or 1 reads as off, and the service's start-up log says so at Error. A machine on a release from before the feature existed never opens the window, restarts a reader or reports, whatever the policy says.

There is no policy for the PKI licence. Workstation 1.0's template carried one, and it was removed in 1.1.0: an Admitted machine is handed its Server's licence on every connection, so a renewal is an edit and a restart on the Server, never a GPO update. A domain that published the 1.0 policy can unlink it at leisure, because the value it leaves is not read.

There is deliberately no policy for the Installer Key: a key change is a staged rollout (name the new key beside the old one on the Server, update the machines, drop the old entry), not a GPO refresh.

Repairing and re-pointing

A repair reinstalls the package and rewrites the registry values from the properties, which is how you change a machine's install-time configuration without uninstalling it:

# Repair: put back what a machine lost, keeping its current configuration.
msiexec /i TrustBridge-Workstation-1.10.0-x64.msi /qn REINSTALL=ALL REINSTALLMODE=ecmus

# Re-point: the same transaction, with a new value.
msiexec /i TrustBridge-Workstation-1.10.0-x64.msi /qn REINSTALL=ALL REINSTALLMODE=ecmus `
    SERVER_URL=https://trustbridge-2.example.com

A property you do not pass is re-read from the machine and written back unchanged. The service is stopped and started by the transaction, so a re-point takes effect when the repair finishes. The Tray App is closed and not started again: a repair does not change the version, so the service does not restart it, and each user's Tray App returns at their next sign-in, or at once from the Start menu's TrustBridge shortcut. The machine keeps its Workstation Key, so it is the same workstation to its Server. A re-point to a different Server arrives in that Server's queue as a new Pending machine.

A re-point reinstalls no files (since Workstation 1.6.0). When SERVER_URL differs from the value the machine holds, the package narrows the reinstall mode to mus itself, however the transaction was started, so it does not look for the package's files at the source the machine was installed from. A machine updated by its Server no longer has that source, because the update deletes its copy of the package. Such a machine can therefore be re-pointed without the MSI, by its product code (see Uninstalling a machine for finding it):

msiexec /i '{product code}' /qn REINSTALL=ALL SERVER_URL=https://trustbridge-2.example.com

A repair that keeps the URL still reinstalls the files, and still needs the package.

The maintenance screen is also one click from the Tray App. On the Service tab, Change Server… under the Server address opens Windows Installer's cached copy of the installed package at its maintenance screen. It changes nothing itself: the URL is still typed into the installer and saved by its Repair, which asks for an administrator, so everything above holds. The button is offered only where the URL comes from the SERVER_URL preference: where Group Policy sets it, the address reads (set by Group Policy) and the button is disabled, because a repair would write a value the policy goes on overriding.

Upgrading

A newer MSI installs over an older one. That is the whole procedure.

msiexec /i TrustBridge-Workstation-1.10.0-x64.msi /qn

No properties are needed; the new package reads the machine's existing values before the old product is removed and writes them back. An upgraded machine is the same workstation, with no PINs to re-enter:

Survives an upgrade	Why
The Workstation Key	It lives in a CNG container no installer table names
The PIN Cache, its key ring, the cached Trusted CA set, the A1 PINs, the record of the last Server-delivered update	Files under C:\ProgramData\TrustBridge\ that no component carries
ServerUrl, InstallerKey, InsertionPrompt, RestartFailedReaders, WorkstationReport	Re-written from the machine's own values
The pt-BR user interface	The satellite assemblies are replaced rather than stranded

The Tray App is closed by the installer on the way through, terminated rather than asked: a close message reaches the Tray's windows and not the process (its main window hides on close while there is an icon, and closing the icon's own hidden window leaves a Tray with no icon), so asking would leave its files in use. It holds nothing worth a graceful goodbye, since the PINs it prompts for live in the service, and that is what keeps an upgrade from ending in a reboot. The upgraded service starts it again in every signed-in session as soon as it is running, and the Tray App says TrustBridge was updated once to each user. A downgrade is refused: going back is a true uninstall, with everything Uninstalling a machine says.

Upgrading from 1.0.x also removes the PkiLicense value the old package wrote; the machine's licence comes from its Server from then on.

Which Server a release needs

Each workstation release speaks one protocol version, and a Server accepts its own version and the one before it.

Workstation	Protocol	Servers that accept it
1.8.1 to 1.10.0	6	1.15.0 and later. Deliver it with 1.20.0 or later, for its Workstation Report, and 1.10.0 with 1.23.0 or later to see its console (below)
1.8.0	6	1.15.0 and later. Deliver it with 1.20.0 or later, for its Workstation Report (below)
1.6.0 and 1.7.0	6	1.15.0 and later
1.5.0	5	1.13.0 and later. From 1.15.0 it is never chosen for a per-transaction session (below)
1.4.0 to 1.4.2	4	1.9.0 to 1.14.1. On 1.13.0 and 1.14.x it connects but serves no new sessions
1.1.0 to 1.3.0	3	1.7.0 to 1.12.0

For almost every release the order is the Server first, then the workstations within one release. A machine newer than its Server's window cannot connect at all: the Server refuses the handshake with update the Server first, hands it no licence, and every certificate on it reads UNTRUSTED until the Server catches up.

From Workstation 1.8.0 the rule has Server 1.20.0 as its floor. 1.8.0 to 1.10.0 speak protocol 6, as 1.6.0 and 1.7.0 do, so a Server from 1.15.0 on lets them connect. But 1.8.0's Workstation Report can be larger than the 32 KB a workstation message could be before Server 1.20.0, and an earlier Server closes the connection of a machine that sends one that large, which a machine with many tokens, middleware or errors can. Workstation 1.8.1 keeps its reports under 32 KB until its Server has taken one, so it stays connected to an earlier Server; deliver it and the releases after it with Server 1.20.0 or later all the same, the first Server that takes the report.

Workstation 1.9.0 and 1.10.0 need nothing newer to connect. What they add rides protocol 6 as optional fields that an earlier Server ignores: the reason a machine could not show a PIN prompt (Workstation 1.9.0 for a per-transaction prompt, 1.10.0 for a session's), which the Audit Log records from Server 1.22.0 and the Workstations screen says in words from Server 1.23.0, and the console in the Workstation Report (Workstation 1.10.0), which the Workstations screen shows from Server 1.23.0. To move a fleet to 1.10.0:

1. Move every machine still on 1.4.x to Workstation 1.5.0 first, if the Server is older than 1.15.0: Server 1.15.0 and later refuse 1.4.x at the handshake.
2. Upgrade the Server to 1.20.0 or later, 1.23.0 or later to see the console, and upload the 1.10.0 package on its Workstation Releases screen.
3. Offer 1.10.0 to the fleet (Server-delivered updates). A machine on 1.6.0 to 1.9.0 keeps serving every session meanwhile; one on 1.5.0 serves every session except one whose Client Application has Per-Transaction PIN on, so turn that on only once its holders' machines run 1.6.0 or later.

Workstation 1.7.0 needed no Server change: it added the Insertion Prompt, which never reaches the Server, and kept protocol 6.

Workstation 1.5.0 and Server 1.13.0 were the exception: they moved together. On protocol 5 the Server stops sending any machine the client application's PIN, and a Server 1.13.0 or 1.14.x sends a 1.4.x machine no PIN challenge and no prompt, so for new sessions it counts as offline.

Going back to an earlier Workstation is not an install over it. The package refuses a downgrade, so it means a true uninstall first, which purges the machine's identity: it asks to be admitted again.

See Operations for the Server side.

Server-delivered updates

From 1.4.0 on, a machine can also take a release from its Server, with nobody at it. An Administrator uploads the signed MSI on the admin console's Workstation Releases screen and offers it to machines on the Workstations screen; each machine offered it installs it by itself. It is the same major upgrade as the msiexec line above: everything in the table survives it, and the Tray App comes back the same way. A machine on 1.3.0 or older has no code to take one, reads as Needs a manual update on the Workstations screen, and is offered nothing.

What a machine does with an offer, in order:

1. Waits a random delay of up to ten minutes, drawn once per offer, so a fleet offered a release at once does not reach the Server in the same second.
2. Downloads it from its Server into C:\ProgramData\TrustBridge\updates\, which only SYSTEM and Administrators can write. An interrupted download resumes where it stopped.
3. Verifies it, and refuses it at the first check that fails, whatever the Server said about it: the SHA-256 and length the Server announced; the Authenticode signature; an RFC 3161 timestamp; a signer on the Publisher Pin compiled into the Service already installed; revocation, where only a pass or a question that could not be answered gets through; the TrustBridge Workstation's own UpgradeCode; a ProductVersion equal to the offer and above the installed one. So the worst a compromised Server can do through this channel is install a genuine, newer release early.
4. Waits until nothing is in progress: no signature in flight and no PIN prompt open. Then, for up to two minutes, it refuses new signatures and prompts (a sign fails saying the machine is installing an update; a prompt moves to another machine) and starts msiexec /i <package> /qn /norestart /l*v <log> detached, so the install outlives the Service it stops. An open Signing Session carries on after the restart, but cached PINs do not survive it unless PinCache:SurviveRestart is on, so holders may be asked for a PIN again.

Each machine reports how it went on its next handshake, and the Workstations screen and the Audit Log show it:

• installed, once the new Service has started at the new version;
• failed, with msiexec's exit status and the stretch of its log that led up to the action that failed. An install that wrote no exit status within thirty minutes, or whose msiexec could not be started, is reported failed too;
• or refused, naming the check that failed.

A failed or refused release is not tried again until it is offered again: offer it again, or use Deliver to all not yet updated, and each machine tries once more, including one that was off at the time, at its next handshake. An install Windows Installer was too busy to start (msiexec exit 1618, another install in progress) reports nothing and is tried again about fifteen minutes later.

The package is deleted once the outcome is known, and so is what a withdrawn or replaced offer left half-downloaded. The five newest install logs stay in updates\, as install-<version>-<time>.log with the time in UTC.

Withdrawing an offer stops every machine that has not started msiexec, even one halfway through the download or waiting for its idle moment. A machine that already installed the release stays on it: there is no way back but a higher version.

Group Policy turns it off. A machine whose Take updates from the TrustBridge Server policy is disabled downloads and installs nothing, whatever it is offered, from the next time its Service starts (ServerUpdates:Enabled).

Uninstalling a machine

An uninstall takes TrustBridge off the machine, and it is not the reverse of an upgrade. It is done on the machine and leaves the machine's row on the Server; taking it off the Server is Revoke or Remove, at the end of this section.

msiexec /x TrustBridge-Workstation-1.10.0-x64.msi /qn

Or, without the MSI to hand, by product code:

$product = Get-ChildItem HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall |
    Where-Object { $_.GetValue('DisplayName') -eq 'TrustBridge Workstation' }
Start-Process msiexec -Wait -ArgumentList "/x $($product.PSChildName) /qn"

What an uninstall destroys, and nothing else does:

The Workstation Key	Deleted from both the TPM and the software store by the service's own purge-machine-identity verb, which the uninstall schedules
C:\ProgramData\TrustBridge\	The whole machine-state tree: PIN Cache, key ring, cached Trusted CA set, A1 PINs, the version that last started, anchors, and updates\ with its record, install logs and any download. Plus a relocated PIN Cache, if PinCache:StorePath or PinCache:KeyRingPath moved one out of the tree
HKLM\Software\TrustBridge	Every value
The service, the Tray App, the autostart entry, the Start menu shortcut	Ordinary removal
HKLM\Software\Policies\TrustBridge	Untouched. It is the policy engine's
HKCU\Software\TrustBridge\Tray App, per user	Untouched. One string, the Tray App version that user last ran. A per-machine package cannot reach every user's hive

The purge runs on a true uninstall and never on the uninstall leg of an upgrade. An uninstall completes even when the purge does not; the verb then writes a loud Application log entry naming what it left behind.

Reinstalling afterwards produces a genuinely new machine: it returns to the queue with a new fingerprint, its holders re-enter their PINs, and every A1 PIN has to be set again at the machine's console.

So the last step is on the Server, and it is one of two. An uninstall is housekeeping on the machine, not a guarantee to the platform, and the machine's row stays on the fleet screen until somebody acts on it there, in that machine's own panel at /admin/fleet:

• Revoke it when its key must stay refused: a machine lost, stolen or compromised, or one whose purge you cannot vouch for. Revocation is the control that does not need the machine's cooperation. A Revoked machine cannot walk back to Pending, and its key stays refused for as long as its row stands, so do not also Remove a machine whose key must stay out.
• Remove it when the machine is simply gone: retired, reimaged, or a test leftover (Server 1.21.0). The Server forgets it: its row, its certificates and its Workstation Report go, while its signing history and its Audit Log entries stay, the lists naming it removed workstation with the first group of its id. The confirmation asks for the machine's hostname. Remove is housekeeping, not a security control: a key that comes back afterwards is a stranger in the admission queue, admitted only if somebody admits it. That holds for a Revoked machine too: removing it lifts the refusal its key was held to.

When an install fails

What you see	What it is	What to do
Exit code 1603, log names SERVER_URL	The launch condition	Pass SERVER_URL=https://…. The scheme is not optional.
Exit code 1603, log says a newer version is installed	A downgrade	Remove the newer package first, having read Uninstalling a machine.
Rolls back at Starting services	The service refused to start: an INSTALLER_KEY that will not parse, or a registry value of the wrong type	The Application event log names the value it refused.
A files-in-use screen listing the Tray App	An interactive upgrade or removal	Continue. The Tray is terminated before any file is touched; no reboot results.
Unknown publisher on the elevation prompt, a SmartScreen hold, or a publisher-requiring policy refusing the package	An unsigned package, which is never a release	Use the release package and check it first: The signature.
Succeeded, but the machine is not in the queue	Almost always the URL; occasionally a policy value overriding what you passed	If the machine never appears in the queue above.
Succeeded, but every certificate reads UNTRUSTED	No PKI licence yet. The machine's only source is its Server: the machine is Pending, cannot reach its Server, is newer than its Server (update the Server first in its log), or the Server's licence is one the SDK refuses	Admit the machine, or upgrade the Server. If it is Admitted and connected, renew Certificates:Validation:License on the Server and restart the Server; the machine applies it when it reconnects. The Tray App's licence line says which case it is.