Windows - Software - Install Twingate (64-Bit)

What the Twingate ZTNA client deployment does on Windows

This Automox Worklet™ deploys the Twingate zero-trust network access client to 64-bit Windows endpoints. Twingate replaces the traditional VPN concentrator with a per-app, identity-bound tunnel that brokers access to internal resources without exposing them on the public internet. The Worklet pulls the latest signed Twingate_x64.msi from the Automox cache and runs a silent install with your tenant network name already wired in.

Evaluation searches the HKLM uninstall keys under SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall and SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall for a DisplayName matching Twingate. If the client is already present, the Worklet exits 0 and does nothing. If it is missing, the Worklet checks for .NET Desktop Runtime 8.0.0 or later by reading the Microsoft.WindowsDesktop.App sharedfx subkeys under HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x64\sharedfx across both Registry32 and Registry64 views, then falls back to scanning Microsoft.WindowsDesktop.App folders under %ProgramFiles%\dotnet\shared and %ProgramFiles(x86)%\dotnet\shared on disk.

Remediation downloads the MSI to ProgramData\amagent\WorkletCache\WSE-572, runs msiexec.exe with /i, /qn, /norestart, and /l*v Twingate_install.log in the same directory. The Worklet appends optional MSI properties from your policy parameters: network for the Twingate tenant name, no_optional_updates to disable the in-client updater on endpoints without local admin, and ncsi_global_dns to fix the false 'no internet' indicator some users see while connected. After msiexec completes, the Worklet re-runs the registry check to confirm Twingate now appears in the uninstall keys, then deletes the staged .exe, .msi, and .cab files from the cache directory.

Why deploy Twingate from a policy instead of a download link

A self-service Twingate download works for ten engineers and fails the moment you cross departments. End users skip the network name field and create authentication loops, or install on a host without .NET Desktop Runtime 8 and crash the connector at first launch. Others accept the default optional-updates setting on a workstation where they have no local admin rights, leaving the client unable to apply its own updates. Manual installs also leave you no inventory: there is no central record of which endpoints have the connector, which are stale, and which never got it at all.

ZTNA rollouts succeed or fail on consistency. This Worklet carries the same signed Twingate MSI, the same .NET dependency gate, and the same network parameters to every 64-bit Windows endpoint under Automox management, so the rollout finishes at the speed of the slowest endpoint instead of the speed of the slowest help-desk ticket. A new laptop joining the fleet inherits Twingate on the next evaluation cycle, with the correct network already pinned.

How the Twingate MSI rollout works

1. Evaluation phase: The Worklet calls Test-ApplicationInstall to search both the 64-bit and Wow6432Node uninstall keys for a DisplayName matching Twingate. If found, it exits 0 (compliant). If missing, it calls Test-DotNetDesktopRuntime against the Microsoft.WindowsDesktop.App sharedfx registry key across both registry views and the on-disk shared folder. If .NET Desktop Runtime 8.0.0 or later is missing, the Worklet returns Exit 1 to suppress a pointless remediation pass. If the runtime is present, it returns Exit 2 to flag the endpoint for install.

2. Remediation phase: Add-WorkletCache creates ProgramData\amagent\WorkletCache\WSE-572. The script downloads Twingate_x64.msi from the Automox cache endpoint (api.automox.com cache, name=Twingate, os=Windows, arch=64) using System.Net.WebClient, then assembles the argument list /i, the MSI path, /l*v Twingate_install.log, /qn, and /norestart. It appends network, no_optional_updates, and ncsi_global_dns as MSI properties when their policy parameters are set. msiexec.exe runs synchronously, the Worklet re-runs Test-ApplicationInstall to confirm the registry now reports Twingate, and Start-AppInstallCleanup deletes the staged .exe, .msi, and .cab files. The Worklet exits 0 on success or 1 with the log path on failure.

Twingate deployment requirements

• Windows 8 or later, 64-bit, workstation or server. The MSI bundle is x64-only; Wow6432Node detection covers 32-bit registration on a 64-bit host.

• PowerShell 5 or later. The evaluation and remediation scripts call .NET registry APIs and System.Net.WebClient, both of which require the full PowerShell host shipped with Windows 8 and later.

• .NET Desktop Runtime 8.0.0 or later (x64) installed under %ProgramFiles%\dotnet\shared\Microsoft.WindowsDesktop.App. The Worklet exits with an error rather than silently installing the runtime; pre-stage it with a separate policy, or flip $installDependencyIfMissing to $true inside remediation.ps1 to enable auto-install from the Automox cache.

• Outbound HTTPS reachability from the endpoint to api.automox.com so the Worklet can fetch the latest signed MSI. Verify with Test-NetConnection api.automox.com -Port 443.

• Active Twingate tenant and a network name to bind the client to (for example, beamreach.twingate.com). Set the network parameter on the policy so end users skip the manual network-name entry.

• Optional parameters: no_optional_updates (recommended on locked-down endpoints where end users do not have local admin rights) and ncsi_global_dns (set when users see a false 'no internet' indicator while connected through Twingate).

Expected state after Twingate is deployed

The Twingate uninstall entry appears in HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall (or the Wow6432Node mirror) with a DisplayName matching Twingate. Verify with Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*' | Where-Object DisplayName -match Twingate, and confirm the client binaries are present under C:\Program Files\Twingate. The next evaluation pass finds the uninstall entry and exits 0 without re-running msiexec, so a recurring policy is safe and idempotent.

On next sign-in, end users launch the Twingate client with your tenant network name already pinned and complete authentication against your identity provider on first connect. The install log at C:\ProgramData\amagent\WorkletCache\WSE-572\Twingate_install.log captures msiexec exit codes and MSI property values for any endpoint that fails. Exit code 0 indicates the registry now reports Twingate; exit code 1 means either the .NET Desktop Runtime dependency was missing in strict mode or msiexec itself returned a non-zero code, and the log is the first place to look. Subsequent Twingate client updates are managed by the in-client updater unless no_optional_updates was set; if it was, pair this Worklet with a separate update policy that re-runs the deploy step on a cadence.