Windows - Software - Close-Patch-Reopen TeamViewer/TeamViewer Host

What the TeamViewer close-patch-reopen Worklet does

This Automox Worklet™ upgrades EXE-installed TeamViewer and TeamViewer Host to the latest version published in the Automox Software Catalog cache. The Worklet inspects C:\Program Files\TeamViewer and C:\Program Files (x86)\TeamViewer for TeamViewer.exe and TeamViewer_Service.exe, reads the FileVersion attribute on each binary, and falls back to the Automox Get-Win32App inventory when an EXE is missing from the expected path.

When an older version is detected, the Worklet runs a three-step close-patch-reopen sequence. It stops the TeamViewer and TeamViewer_Service processes to release file locks, downloads the latest EXE installer from the Automox cache API into ProgramData\amagent\WorkletCache\TeamViewerEXEUpdate, and runs the installer silently with /S and /allusers. After the installer returns exit code 0, 3010, or 1641, the Worklet relaunches the product from the same path used during detection.

TeamViewer and TeamViewer Host are handled independently, so an endpoint running both products updates each one in turn. MSI-based TeamViewer deployments are intentionally out of scope. If neither EXE is present, the Worklet exits cleanly and no installer is downloaded.

Why patch TeamViewer at fleet scale

TeamViewer is a high-value target for credential theft and lateral movement. CVE-2020-13699 exposed a URI handler NTLM credential leak, and CVE-2024-7479 and CVE-2024-7481 covered driver installation privilege escalation in the TeamViewer Remote client. Host-service hardening fixes ship on a steady cadence, and an unpatched TeamViewer build is a remote-access vector sitting on every workstation that runs it.

Manual patching falls behind on the workstations where it matters most: the ones with a user who dismissed the upgrade prompt or kept a support session open through the last maintenance window. Apply this Worklet through the patch policy that covers your Windows workstations so TeamViewer.exe is closed, the silent installer for the published build runs, and the application is restarted in the same user context on every endpoint. The sequence avoids a reboot, which is the specific reason TeamViewer patching stalls on workstations with users who will not approve one.

How the close-patch-reopen sequence works

1. Evaluation phase: The Worklet walks the configured EXE paths for TeamViewer (TeamViewer.exe) and TeamViewer Host (TeamViewer_Service.exe and TeamViewer.exe). It pulls the FileVersion via [System.Diagnostics.FileVersionInfo]::GetVersionInfo and falls back to the Automox Get-Win32App inventory when the binary is missing from the expected path. The script then queries https://api.automox.com/api/cache?cmd=getLatestVersion with the product name, os=Windows, and arch=64 or 32 derived from [Environment]::Is64BitOperatingSystem. If the installed [Version] is less than the catalog [Version], the endpoint is flagged with exit code 2. A failed cache call also flags the endpoint, so a network blip never lets a known-vulnerable build linger.

2. Remediation phase: For each detected product, the remediation script runs Stop-Process -Force against TeamViewer and TeamViewer_Service to release file locks. It calls the cache downloadLatestVersion endpoint to pull the latest EXE into ProgramData\amagent\WorkletCache\TeamViewerEXEUpdate. The script invokes the installer with Start-Process -ArgumentList "/S","/allusers" -WindowStyle Hidden, guarded by a 300-second Wait-Process timeout that catches installer hangs. Exit codes 0, 3010 (reboot required), and 1641 (reboot initiated) count as success. The script then runs Start-Process against the original EXE path to bring TeamViewer back up. The Worklet exits 0 on success or 2 on failure with details written to stderr.

TeamViewer patch requirements

• Windows 10, Windows 11, or Windows Server 2016 or later, on workstation or server SKU

• PowerShell 5.1 or later (the default shell on every supported Windows build)

• EXE-installed TeamViewer or TeamViewer Host under C:\Program Files\TeamViewer or C:\Program Files (x86)\TeamViewer; MSI deployments are skipped

• Outbound HTTPS reachability to https://api.automox.com for cache lookups and installer downloads

• Local Administrator privileges (the default Automox agent context) to stop processes, write into Program Files, and run the installer

• At least 300 MB free under ProgramData\amagent\WorkletCache\TeamViewerEXEUpdate for the cached installer payload

• Optional: override the cache directory by setting the tempPath parameter when invoking the remediation script

Expected TeamViewer state after the patch

After remediation, Get-ItemProperty 'C:\Program Files\TeamViewer\TeamViewer.exe' | Select-Object VersionInfo returns the latest release listed in the Automox Software Catalog, and the TeamViewer About dialog reflects the same build number. The TeamViewer_Service service comes back up under its normal account, and the user-mode TeamViewer.exe relaunches into the system tray. The next evaluation pass exits 0 with the message "TeamViewer and TeamViewer Host (EXE) are compliant or not present."

Active remote support sessions are interrupted briefly during the close step and pick back up once the new build relaunches and the user reconnects. For workstations with critical in-flight sessions, schedule the policy inside a maintenance window or trigger it on demand from the Automox console using Fix Now so the timing is under operator control. Run the evaluation alone first if you want to inventory which endpoints would update without committing to the install pass.