Windows - Software Lifecycle - Install Putty

What the PuTTY deployment Worklet does

This Automox Worklet™ deploys PuTTY to Windows endpoints. PuTTY is the open-source SSH, Telnet, rlogin, and serial console client that IT administrators, developers, and network engineers use to reach Linux servers, network switches, routers, firewalls, and console-port-attached hardware.

The Worklet checks the Windows registry uninstall hive for a PuTTY DisplayName entry on both 64-bit and 32-bit views. When the entry is missing, the remediation script stages the MSI under %ProgramData%\amagent\WorkletCache\WSE-763\, downloads the architecture-appropriate installer from the Automox API cache, and runs msiexec with the /qn, /norestart, ALLUSERS=1, and /l*v logging arguments. Installs land in %ProgramFiles%\PuTTY by default and place putty.exe, pscp.exe, psftp.exe, plink.exe, puttygen.exe, and pageant.exe on disk.

The remediation script enforces a five-minute timeout via Wait-Process so a hung MSI does not stall the Automox policy. Exit code 0 indicates a clean install; exit code 3010 is treated as success with a pending reboot; any other non-zero MSI exit code is logged and surfaced in the Automox activity log. The installer file is deleted from the cache directory once msiexec returns, so the WorkletCache footprint stays small.

Why deploy PuTTY through Automox

PuTTY is a common SSH client on Windows admin workstations, so ad-hoc installs accumulate across a fleet. Some endpoints may carry an older 32-bit build downloaded from a third-party mirror, while others lack it entirely. End users searching for it can land on lookalike installers that bundle unwanted software or trojanized binaries. The 2024 PuTTY private-key recovery vulnerability (CVE-2024-31497, affecting versions 0.68 through 0.80 with NIST P-521 keys) is a recent reminder that an SSH client is part of the attack surface, not a neutral tool.

Schedule this Worklet once and the next evaluation pass deploys PuTTY to every endpoint that is missing it. The policy replaces tampered or out-of-date installs the next time the original is removed and gives the help desk a single supported source for the binary.

How PuTTY deployment works

1. Evaluation phase: The Worklet opens the HKLM registry uninstall hive in the correct registry view for the OS architecture. It reads subkeys under SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall and SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall, then matches each DisplayName value against the string "Putty". A match exits 0 (compliant). No match exits 2 and flags the endpoint for remediation.

2. Remediation phase: The Worklet creates %ProgramData%\amagent\WorkletCache\WSE-763\ via New-WorkletCache, selects the 64-bit or 32-bit MSI URL based on [System.Environment]::Is64BitOperatingSystem, downloads the MSI with System.Net.WebClient, and runs msiexec /i Putty.msi /l*v Putty_install.log /qn /norestart ALLUSERS=1 under Start-Process. Wait-Process applies a 300-second timeout; the process is stopped if it overruns. On success the installer MSI is deleted from the cache directory; the install log remains for audit.

PuTTY deployment requirements

• Windows workstation or server endpoint with PowerShell 3.0 or later (covered by Windows 10, Windows 11, and Windows Server 2012 R2+)

• Outbound HTTPS reachability from the endpoint to api.automox.com on port 443 for the MSI download

• TLS 1.2 enabled on the endpoint; the script catches the SSL/TLS handshake error and reports it explicitly when 1.2 is disabled at the OS level

• Local administrator context (the Automox agent already runs as SYSTEM, which satisfies the MSI ALLUSERS=1 install)

• Write access under %ProgramData%\amagent\WorkletCache for the staging directory

• No policy variables to set; appName, install directory, MSI URL, and argument list are all predefined in remediation.ps1

Expected state after PuTTY deployment

After remediation, %ProgramFiles%\PuTTY\ contains putty.exe, pscp.exe, psftp.exe, plink.exe, puttygen.exe, and pageant.exe. A PuTTY (64-bit) or PuTTY entry appears under SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall (or the Wow6432Node mirror on 32-bit installs), and PuTTY shows up in Settings > Apps > Installed apps and in the Start menu. The verbose MSI log lands at %ProgramData%\amagent\WorkletCache\WSE-763\Putty_install.log; keep this file for change-control evidence or to triage failed installs.

To verify on a pilot endpoint, run Get-ItemProperty HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\* | Where-Object DisplayName -match 'PuTTY' | Select-Object DisplayName, DisplayVersion, InstallLocation in an elevated PowerShell prompt. Then launch C:\Program Files\PuTTY\putty.exe and confirm the version dialog under Help > About PuTTY. Subsequent Worklet evaluations on the same endpoint detect the DisplayName entry, exit 0, and skip remediation, so the policy is safe to leave on a recurring schedule for continuous coverage of newly enrolled endpoints.