Windows - Software - Uninstall Palo Alto GlobalProtect

What the GlobalProtect removal Worklet does

This Automox Worklet™ uninstalls Palo Alto GlobalProtect from Windows endpoints by enumerating every registered instance of the client in the system uninstall registry. The Worklet inspects both the native 64-bit hive at HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall and the 32-bit compatibility hive at HKLM:\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall. Each matching DisplayName is captured along with its UninstallString, which is the value the Worklet uses to drive the removal.

GlobalProtect ships in two packaging formats. Recent versions register an MSI at C:\Program Files\Palo Alto Networks\GlobalProtect\GlobalProtect64.msi and remove cleanly with msiexec /x {ProductCode} /qn /norestart. Older or repackaged versions register an executable uninstaller that accepts the /S silent switch. The Worklet inspects the UninstallString format, picks the correct removal path for each instance, and runs the command in a 64-bit PowerShell context so the Wow6432Node redirector does not hide the application from the agent.

The Worklet then validates the result against the documented Windows Installer exit codes. Exit 0 means the uninstall completed cleanly. Exit 1641 means the installer requested a reboot and triggered it. Exit 3010 means a soft reboot is pending. Any other code is treated as a failure and surfaced to the Automox activity log so an admin can triage the endpoint without re-running the policy blind.

Why retire GlobalProtect at fleet scale

VPN client retirement is rarely a single decision applied uniformly. A subset of endpoints gets migrated to a new ZTNA platform, another subset still needs the legacy VPN, and a long tail keeps an orphaned GlobalProtect install long after the user has switched tunnels. Orphaned clients hold open service handles on PanGPS and PanGPA, register adapter drivers that fight the new VPN stack, and routinely surface as helpdesk tickets when split-tunnel rules collide. Pulling the old client cleanly is the prerequisite for every clean cutover.

Scheduling this Worklet against the migration cohort runs the silent msiexec /x against the GlobalProtect ProductCode on every Windows endpoint in scope, stops the PanGPS and PanGPA services first so the MSI does not block on running processes, and reports back which endpoints completed, which returned 3010 (reboot required), and which need manual attention. The cutover plan stops depending on whether the end user has signed in this week, and the activity log produces the per-host evidence a security review will ask for after the new ZTNA platform is in place.

How GlobalProtect removal works

1. Evaluation phase: The Worklet enumerates HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall and HKLM:\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall, filtering on DisplayName that matches GlobalProtect. Each match contributes a record with the DisplayName, DisplayVersion, UninstallString, and a flag for whether the install is MSI-based (UninstallString begins with msiexec) or executable-based. The endpoint is flagged non-compliant if any matching record is found. If the registry shows no GlobalProtect entries the Worklet exits clean without scheduling remediation.

2. Remediation phase: The Worklet re-launches in 64-bit PowerShell so it can see both registry hives. For MSI installs it parses the ProductCode from the UninstallString and runs msiexec.exe /x {ProductCode} /qn /norestart. For executable installs it runs the registered uninstaller with /S to suppress the GUI. Each invocation is wrapped with Start-Process -Wait so the Worklet captures the real exit code. Codes 0, 1641, and 3010 are treated as success; anything else is logged with the failing UninstallString so the admin can reproduce the call manually. The Worklet re-reads the registry after the run to confirm the GlobalProtect entry is gone before exiting.

GlobalProtect removal requirements

• Windows 10, Windows 11, or Windows Server 2016 and later (legacy Windows 7 and Server 2008 R2 endpoints are also supported when the Automox agent is installed)

• The Automox agent must run with administrator privileges to invoke msiexec and modify HKLM

• GlobalProtect must be a registered Windows application with a valid UninstallString in HKLM (sideloaded copies that skip the installer registry are not detectable)

• Schedule the policy during a maintenance window when GlobalProtect is not the active tunnel, or pre-stage the replacement VPN client so endpoints retain network access after removal

• FixNow compatible for immediate one-shot execution against a target group from the Automox console

Expected state after GlobalProtect removal

After a successful run the GlobalProtect application no longer appears in Settings > Apps > Installed apps or in the legacy Control Panel uninstall list. The C:\Program Files\Palo Alto Networks\GlobalProtect directory is removed by the installer, the PanGPS and PanGPA services are deregistered, and the GlobalProtect virtual network adapter is unbound. The uninstall registry keys under both HKLM hives are gone, which is what the next evaluation pass uses to confirm the endpoint is compliant.

Validate from the endpoint with Get-ItemProperty HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\* | Where-Object DisplayName -match GlobalProtect – the command returns nothing when removal is complete. Cross-check with Get-Service PanGPS -ErrorAction SilentlyContinue and Get-NetAdapter | Where-Object Name -match GlobalProtect. If a 3010 exit code was reported, the endpoint will fully release the adapter and service handles only after the next reboot, so plan a follow-up evaluation after the reboot policy runs to close the loop.