Upgrade Python

What the Python Upgrader does

This Automox Worklet™ detects outdated Python installations and upgrades them to a version you specify. Unlike system-wide software, Python typically installs per-user under HKEY_USERS rather than HKEY_LOCAL_MACHINE. The Worklet scans all user registry hives to find Python installations matching the target version series.

Python treats each major.minor version (like 3.9 or 3.10) as a separate installation. This Worklet upgrades within a version series (e.g., 3.9.1 to 3.9.5) but cannot upgrade across series (e.g., 3.5 to 3.9). For cross-series upgrades, you need to install the new version alongside the old one.

The Worklet creates temporary scheduled tasks that run the Python installer in the user context. This approach addresses Python's per-user installation model. After the installer completes, the scheduled task is automatically removed. Both 32-bit and 64-bit Python installations can coexist and are upgraded independently.

Why upgrade Python through Automox

Python releases frequently include security patches for vulnerabilities in the interpreter, standard library, and SSL/TLS handling. Outdated Python versions may contain known exploits that attackers can leverage through malicious scripts or compromised packages. Keeping Python current protects developer workstations and production servers.

Development teams often have Python installed on workstations for scripting, automation, and application development. Manually tracking Python versions across endpoints is impractical. Automox provides visibility into which versions are deployed and automates the upgrade process across your fleet.

The Worklet supports environments where multiple Python architectures are installed on the same endpoint. Developers working with both 32-bit and 64-bit libraries can maintain both installations without manual intervention.

How Python upgrades work

1. Evaluation phase: The Worklet mounts HKEY_USERS as a PowerShell drive and iterates through each user profile's SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall registry key. It searches for Python entries matching the target version series (e.g., 3.9.*). If any installation has a DisplayVersion lower than $appVersion, the endpoint is flagged for remediation.

2. Remediation phase: The Worklet scans user hives again to identify 32-bit (DisplayName contains "32") and 64-bit (DisplayName contains "64") Python installations needing upgrades. For each, it creates a Windows scheduled task that runs the appropriate installer ($32bitFilename or $64bitFilename) with /quiet argument in the Users context. The task executes immediately and is deleted after completion.

Python upgrade requirements

• Windows 7 or later (Python 3.9+ requires Windows 10)

• PowerShell 2.0 or later

• Python already installed in the target version series (cannot cross-upgrade, e.g., 3.5 to 3.9)

• Upload both 32-bit and 64-bit Python installers to the Automox console

• Configure $appVersion with target version (e.g., '3.9.5')

• Configure $32bitFilename (e.g., 'python-3.9.5.exe') and $64bitFilename (e.g., 'python-3.9.5-amd64.exe')

Expected state after Python upgrade

After successful remediation, Python runs the target version for all upgraded user installations. The registry DisplayVersion reflects the new version. Existing virtual environments may need recreation to use the upgraded interpreter, though pip packages typically remain accessible.

If installation fails, the Worklet exits with code 1 and outputs the error. Common issues include incorrect installer filenames, missing installer files in the console payload, or permission conflicts with scheduled task creation. Check that the installer filenames exactly match the uploaded files including the .exe extension.

How to validate upgrade python changes

1. Run this Worklet on a pilot Windows endpoint and review evaluation output for upgrade python.

2. Confirm Automox activity logs show successful completion and exit code 0.

3. Verify endpoint state using checks aligned to evaluation script logic, such as New-PSDrive, Out-Null, Get-ChildItem.

4. Validate remediation effects from script operations such as Split-Path, New-PSDrive, Out-Null, then rerun evaluation for compliance.