MacOS
View all Worklets
MacOSmacOS

macOS - Software Lifecycle - Install TeamViewer Host

Deploy TeamViewer Host to macOS endpoints with the Automox-hosted signed PKG installer for unattended remote support

Worklet Details

What the TeamViewer Host macOS deployer does

This Automox Worklet™ deploys TeamViewer Host to macOS endpoints across your fleet. The Worklet first looks for TeamViewerHost.app in /Applications, and when the bundle is missing it pulls the signed PKG installer through the Automox wdk ottopm download channel, hands the resolved file to the native installer binary, and re-checks the application path before exiting.

TeamViewer Host is the unattended-access variant of the TeamViewer client. The app registers a launchd job so the endpoint is reachable by ID and passcode even when no user is logged in, which is the working pattern most service desks build their remote-support runbooks around. The Worklet installs the build that the Automox content team curates through wdk, so the same package targets Intel and Apple silicon Macs without a per-architecture policy split.

The /Applications/TeamViewerHost.app directory check returns in under a second, so endpoints that already carry the bundle exit 0 with no download. The policy can run alongside a new-hire onboarding policy or a weekly drift sweep without wasted PKG downloads on the Macs that already pass.

Why deploy TeamViewer Host across macOS endpoints

Remote-support coverage is often inconsistent across macOS fleets. New laptops ship to a remote employee, a contractor brings their own Mac, or an existing endpoint loses the TeamViewer agent after a major macOS upgrade. When the service desk gets the ticket, the technician has no inbound path, the user may be on a captive Wi-Fi network, full-disk encryption blocks screen sharing, and walking the user through a manual TeamViewer install over a phone call burns 20 minutes of two people's time.

Apply this Worklet to the macOS endpoint group the service desk supports; the directory check restores TeamViewer Host on the next policy evaluation, before a user files a ticket. The service desk inherits a set of Macs that are already reachable rather than one it has to triage a laptop at a time.

How TeamViewer Host PKG deployment works

  1. Evaluation phase: The Worklet tests for the bundle at /Applications/TeamViewerHost.app using a bash -d directory check. If the bundle exists, the script prints "TeamViewer Host is already installed. No changes are required." and exits 0, which tells the Automox agent to skip remediation on this endpoint. If the bundle is absent, the script exits 1 and remediation is scheduled on the next policy run.

  2. Remediation phase: The remediation script calls /usr/local/bin/wdk ottopm download TeamViewer_Host to fetch the curated PKG, parses the JSON response with /usr/local/bin/wdk ottoq to read .steps[].downloaded_file_path, then runs sudo installer -pkg "${installerPath}" -target / to install the package against the boot volume. The script re-checks /Applications/TeamViewerHost.app and exits 0 on success or 1 on failure, so a missing bundle or non-zero installer status surfaces in the Automox activity log instead of silently slipping past the policy.

TeamViewer Host deployment requirements

  • macOS endpoint running on Intel or Apple silicon; the curated PKG covers both architectures

  • Automox agent running as root, which is the default context (installer -pkg requires root to write to /Applications)

  • Automox wdk helpers at /usr/local/bin/wdk (ottopm and ottoq) installed by the Automox agent; the remediation script invokes them directly

  • Outbound HTTPS reachability to the Automox content delivery endpoints so wdk ottopm can pull the signed PKG

  • Privacy and Security configuration (PPPC profile or manual approval) that grants TeamViewer Host the Accessibility, Screen Recording, and Full Disk Access entitlements your remote-support workflow needs

  • A TeamViewer account or enterprise license your support technicians use to connect to the endpoint ID and passcode after installation

Expected state after TeamViewer Host deployment

After a successful remediation, TeamViewerHost.app sits in /Applications, the TeamViewer launchd job is registered, and the endpoint advertises a TeamViewer ID once it reaches teamviewer.com. From the Automox console, the policy reports the endpoint as compliant and stops scheduling remediation on subsequent evaluations until the bundle is removed. From the service-desk side, the technician can search the endpoint by TeamViewer ID and connect for an unattended session as soon as the user grants the one-time Accessibility, Screen Recording, and Full Disk Access prompts (or as soon as the PPPC profile takes effect).

Validate by running ls -d /Applications/TeamViewerHost.app on a pilot Mac and checking the TeamViewer Host menu-bar icon shows a green ready indicator with a 9-or-10 digit endpoint ID. For audit evidence, capture the Automox policy run identifier alongside the output of pkgutil --pkg-info com.teamviewer.teamviewerhost, which records the installed version and timestamp. If TeamViewer Host is later uninstalled by an end user, the next evaluation phase flags the endpoint as non-compliant and the Worklet redeploys the curated PKG on the following policy run, so coverage is self-healing rather than dependent on a one-time onboarding push.

View in app
evalutation image
remediation image

Consider Worklets your easy button

What's a Worklet?

A Worklet is an automation script, written in Bash or PowerShell, designed for seamless execution on endpoints – at scale – within the Automox platform. Worklets deploy named-CVE mitigations within hours of disclosure, perform configuration, remediation, and install or remove applications and settings across Windows, macOS, and Linux.

do more with worklets