Deploy the Zoom client machine-wide to Windows endpoints with automatic 32-bit or 64-bit MSI selection
This Automox Worklet™ deploys the Zoom client to Windows endpoints as a machine-wide MSI install rather than a per-user install. Machine-wide installs land in Program Files and write their uninstall keys under HKLM, so every user account that logs into the endpoint shares one Zoom installation, one version, and one set of MSI policies. Per-user installs land under %LOCALAPPDATA% and create one Zoom instance per profile, which is what most consumer-grade Zoom downloads do by default.
The evaluation script reads HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall and HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall to look for a DisplayName containing "Zoom." A match exits 0 (compliant). No match exits 2, which flags the endpoint for remediation. Per-user installs under %LOCALAPPDATA%\Zoom are deliberately treated as non-compliant because they do not satisfy the machine-wide baseline.
The remediation script downloads the architecture-matched Zoom MSI from the Automox cache endpoint (api.automox.com/api/cache), stages it under C:\temp\Automox\ZoomInstall\, and runs msiexec.exe with /i, /qn, and /norestart. The full MSI verbose log is written to C:\ProgramData\amagent\Zoom64_install.log on 64-bit hosts or Zoom32_install.log on 32-bit hosts. On 64-bit Windows, msiexec is relaunched through sysnative\WindowsPowerShell to avoid the 32-bit redirector trapping the install.
Per-user Zoom installs are the default outcome when an end user clicks the Zoom download page. The installer drops into %LOCALAPPDATA%\Zoom and updates itself from Zoom's auto-update service. That is fine for a personal laptop and a problem on a managed fleet. IT cannot inventory those installs reliably from HKLM, cannot pin a specific MSI version, cannot silence the auto-updater, and cannot push a CVE-driven Zoom upgrade as a uniform task because each user profile holds its own copy. Machine-wide deployment moves Zoom into Program Files\Zoom, registers it under HKLM, and makes it patchable like any other managed application.
Zoom ships frequent security releases, and most fleets carry a mix of per-user MSI installs, EXE installers, and stale builds that ZoomAutoUpdater silently abandons. This Worklet selects the correct 32-bit or 64-bit machine-wide MSI based on the OS architecture, runs it with the all-users flags, and re-validates the install on each evaluation pass. The next Zoom CVE becomes a scheduled patch run instead of an end user hunt across the help-desk queue.
Evaluation phase: The script detects the OS bitness with [System.Environment]::Is64BitOperatingSystem. On 64-bit hosts it opens HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall through the Registry64 view and enumerates subkeys, then checks HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall for 32-bit Zoom installs. On 32-bit hosts it only checks the native uninstall path. Any DisplayName matching "*Zoom*" exits 0 with "Zoom is already installed. Now exiting." No match exits 2 with "Zoom was not found. Flagging for remediation."
Remediation phase: The script creates C:\temp\Automox\ZoomInstall\ and downloads the architecture-matched MSI (Zoom64.msi or Zoom32.msi) from https://api.automox.com/api/cache?cmd=downloadLatestVersion&name=Zoom&os=Windows&arch=64 (or arch=32). It runs msiexec.exe with arguments /i "$scriptDir\Zoom64.msi", /l*v C:\ProgramData\amagent\Zoom64_install.log, /qn, /norestart, and waits up to 300 seconds for the process to exit. Exit codes 0 and 3010 (reboot required) are treated as success. Non-zero exit codes write the failure to stderr and exit 1. The staging directory is removed on every path. On 64-bit hosts the msiexec call is relaunched through %SystemRoot%\sysnative\WindowsPowerShell\v1.0\powershell.exe so the install runs in the native 64-bit context even when the Automox agent is 32-bit.
Windows workstation or server endpoint with the Automox agent installed and running as SYSTEM
Outbound HTTPS connectivity to api.automox.com so the agent can pull the Zoom MSI from the catalog cache
Write access to C:\temp\Automox\ and C:\ProgramData\amagent\ for the staging directory and MSI verbose log
Administrative privileges for msiexec.exe to write to Program Files and register the machine-wide uninstall keys under HKLM
No policy variables are required; the evaluation $appName is hard-coded to "Zoom" and the OS architecture is detected at runtime
If an existing per-user Zoom install under %LOCALAPPDATA%\Zoom should be removed first, pair this Worklet with a separate uninstall task; this Worklet only adds the machine-wide copy
After a successful remediation, Zoom.exe is present under C:\Program Files\Zoom\bin\ (64-bit) or C:\Program Files (x86)\Zoom\bin\ (32-bit) and the uninstall entry appears in HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall with DisplayName "Zoom" and InstallLocation under Program Files. Any user who logs into the endpoint can launch Zoom from the Start menu without a per-user install pass. The msiexec verbose log is preserved at C:\ProgramData\amagent\Zoom64_install.log (or Zoom32_install.log on 32-bit hosts), and the staging directory C:\temp\Automox\ZoomInstall\ is removed.
Validate the deployment by running Get-ItemProperty HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\* | Where-Object DisplayName -like "*Zoom*" and confirming the DisplayVersion matches the version the Automox cache served. Confirm machine-wide scope by checking that the install path begins with Program Files, not %LOCALAPPDATA%. The Automox activity log should show evaluation exit 2 followed by remediation exit 0; on the next scheduled evaluation the endpoint should report exit 0 "Zoom is already installed. Now exiting." If msiexec returns 3010, schedule a reboot policy to clear the pending state; the next evaluation will still pass because the uninstall key was written. Recurring evaluations keep the install pinned, so if a user uninstalls Zoom from Programs and Features the next policy run restores the machine-wide copy without admin intervention.


Loading...
Consider Worklets your easy button
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.

AUTOMOX + WORKLETS™
Uncover new possibilities with simple, powerful automation.
By submitting this form you agree to our Master Services Agreement and Privacy Policy
By submitting this form you agree to our Master Services Agreement and Privacy Policy.
Already have an account? Log in