Windows - Software Lifecycle - Update TeamViewer with Notifications

What the TeamViewer patcher does

This Automox Worklet™ patches outdated TeamViewer installations on Windows endpoints to the latest stable release. The Worklet queries the Automox version cache at https://api.automox.com/api/cache to look up the current TeamViewer build for the endpoint's architecture (32-bit or 64-bit), then compares that build against the installed version reported by Get-Win32App.

When the installed version is older than the cache, the Worklet sends a Yes/No notification to the active user with a configurable title, message, and timeout. If the user accepts, the Worklet stops the TeamViewer.exe and TeamViewer_Service.exe processes, calls Remove-Win32App with the /S silent uninstall flag, downloads the latest TeamViewer Setup.exe to the Worklet cache directory, and runs the installer with /S /allusers so the new build is registered for every profile on the endpoint.

Scope is intentionally narrow. The Worklet targets EXE-installed TeamViewer only. MSI-deployed copies use different uninstall keys and upgrade semantics, and this Worklet exits early on those endpoints rather than risk a broken install. Confirm your deployment method against the registry uninstall keys under HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall before scheduling the policy fleet-wide.

Why patch TeamViewer across the fleet

TeamViewer is a high-value target. The application grants remote interactive control of the desktop, runs a service that starts at boot, and listens for inbound connections under the user's session. Historical CVEs against TeamViewer (CVE-2020-13699 URI handling, CVE-2019-18988 stored credential weakness, CVE-2018-16550 brute-force authentication bypass) show the pattern: an outdated client on one engineer's laptop becomes the foothold an attacker uses to pivot into the corporate network. Patch latency on remote-access software directly translates into dwell time.

Unpatched TeamViewer builds have shipped privilege escalation and certificate validation CVEs across multiple major versions. This Worklet evaluates the installed TeamViewer version on every Windows endpoint, notifies the signed-in user before any disruption, and then runs the signed EXE installer so an active support session is never interrupted mid-call. The EXE distribution path keeps the upgrade aligned with the channel TeamViewer ships through directly.

How TeamViewer patching works

1. Evaluation phase: The Worklet calls Invoke-WebRequest against https://api.automox.com/api/cache and parses the response with ConvertFrom-Json to find the current TeamViewer version for the endpoint's architecture. It then runs Get-Win32App to enumerate installed software, selects the TeamViewer entry, and compares its DisplayVersion against the cache value. Endpoints whose installed build is older than the cache exit non-compliant. Endpoints without TeamViewer present, or already on the latest build, exit 0 with no further action.

2. Remediation phase: The Worklet posts a Yes/No notification through the Automox notification helper (built on top of msg.exe and a WPF dialog under the active session) with a configurable title, message body, and timeout in seconds (default 60). On Yes, it runs Stop-Process against TeamViewer.exe and TeamViewer_Service.exe, calls Remove-Win32App with /S to uninstall the existing copy, downloads the latest TeamViewer Setup.exe from the Automox cache into the Worklet working directory, and invokes the installer with /S /allusers under a 300-second Start-Process timeout. Exit code 0 indicates a successful upgrade; exit code 3 indicates the user declined or the prompt timed out; non-zero installer exit codes are passed through to the Automox activity log.

TeamViewer patch requirements

• Windows workstation or server endpoint with TeamViewer installed via the Setup.exe (EXE) installer, not an MSI

• Internet reachability to https://api.automox.com/api/cache from the endpoint for version lookup and installer download

• TLS 1.2 enabled on the endpoint for the HTTPS calls (set [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 in PowerShell if older defaults still apply)

• An interactive user session for the notification to display; if no user is signed in, the Worklet exits with code 3 rather than force-closing TeamViewer

• Policy parameters: notification title (default Automox Notification), notification message, and prompt timeout in seconds (default 60); set these to match your end user communication tone

• Administrative context for the Automox agent (the default service account already meets this) so Remove-Win32App and the silent installer can write to Program Files and HKLM

Expected state after TeamViewer patching

After a successful run, the endpoint reports the latest TeamViewer DisplayVersion in HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\TeamViewer (or the 64-bit hive on x64 builds), and the TeamViewer service restarts automatically against the new binaries. The application is available for inbound remote support sessions with the current security fixes applied. Re-running the policy reports the endpoint as compliant, because the evaluation phase finds the cache version and the installed DisplayVersion in agreement.

Validate by opening TeamViewer and reviewing Help › About TeamViewer, or by running Get-Win32App TeamViewer | Select-Object DisplayName, DisplayVersion in PowerShell. For audit trail, capture the Automox activity log entry, which records the cache version, the installed version before remediation, and the installer exit code. If the user declined the prompt or the timeout elapsed, the Worklet exits code 3 and TeamViewer remains on the previous version; the next policy run prompts again. Installer failures surface as non-zero exit codes (1603 for generic install failure, 1618 for installer already running) so you can triage in the Automox console without RDP into the endpoint.