Force-Remove Leftover VMware Tools with PowerShell — Registry, File & Service Cleanup

🚀 Overview

Add/Remove Programs says VMware Tools isn't installed. The MSI uninstaller can't find a product to remove. But C:\Program Files\VMware is still sitting there, a handful of VMware* services are still listed in services.msc, and the registry is full of orphaned Installer\Products entries. This usually happens after a botched upgrade, a Tools package that was removed by deleting files instead of uninstalling properly, or — most commonly — a VM that's being prepared for a move off VMware entirely.

This script does the manual job an engineer would otherwise do by hand: find every trace VMware Tools left in the registry and on disk, show you exactly what it found, and — once you confirm — remove all of it cleanly. It's written for Windows Server 2008 R2 through 2019 and has been tested directly on 2016 and 2019.

🔍 Why the Standard Uninstaller Fails

A handful of recurring causes account for most "VMware Tools won't uninstall" situations on generic Windows Server builds:

• The MSI's ProductCode registration in HKEY_CLASSES_ROOT\Installer\Products survived a previous failed uninstall, but the cached MSI package it points to is gone — so Windows Installer has nothing to run.
• Tools was removed by deleting C:\Program Files\VMware directly rather than through the uninstaller, leaving the registry registration completely orphaned.
• The VM was P2V'd, cloned, or template-deployed from a source where Tools was installed differently, leaving installer metadata that doesn't match the running OS.
• A repeated upgrade-then-downgrade cycle left more than one orphaned "VMware Tools" product entry in the registry — the second one is invisible to Programs and Features but still blocks a clean reinstall.

In every one of these cases, the fix isn't "uninstall again" — there's nothing left for the uninstaller to act on. It's a manual cleanup of the leftovers.

🗂️ What Gets Cleaned Up

The script builds its target list dynamically rather than hardcoding paths, so it adapts to whatever installer IDs are actually present on the box in front of it.

✅ Prerequisites & Safety Checklist

📜 How the Script Works

The flow is linear and deliberately simple to follow — discover, build, filter, confirm, remove:

1. Discovering every orphaned installer entry

Rather than assuming there's exactly one "VMware Tools" registration, the script enumerates Installer\Products and collects every match — important because repeated upgrade/downgrade cycles can leave more than one behind:

function Get-VMwareToolsInstallerIDs {
    $found = @()
    Get-ChildItem Registry::HKEY_CLASSES_ROOT\Installer\Products -ErrorAction SilentlyContinue | ForEach-Object {
        if ($_.GetValue('ProductName') -eq 'VMware Tools') {
            $icon  = $_.GetValue('ProductIcon')
            $msiId = $null
            if ($icon) {
                $m = [Regex]::Match($icon, '(?<=\{)(.*?)(?=\})')
                if ($m.Success) { $msiId = $m.Value }
            }
            $found += [PSCustomObject]@{ reg_id = $_.PSChildName; msi_id = $msiId }
        }
    }
    return $found
}

The MSI ProductCode (used to find the matching Uninstall registry key) is pulled out of the ProductIcon value, which embeds it between curly braces.

2. Walking every SID under UserData

This is the part that's easy to get wrong: the per-user MSI registration under UserData isn't always filed under the SYSTEM SID. If Tools was ever installed interactively by an administrator account, the registration sits under that account's SID instead. The script walks all of them:

$userDataRoot = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData"
if (Test-Path $userDataRoot) {
    Get-ChildItem $userDataRoot -ErrorAction SilentlyContinue | ForEach-Object {
        $targets += (Join-Path $_.PSPath "Products\$($entry.reg_id)")
    }
}

3. Filtering before the confirmation prompt

Every computed path is checked with Test-Path before it's shown to you, so the list you confirm against matches exactly what will be touched — no theoretical paths that don't actually exist on this particular server.

4. The confirmation gate (or -Force for automation)

$proceed = $Force.IsPresent
if (-not $proceed) {
    $proceed = (Read-Host "Continue (y/n)") -eq 'y'
}

Run it with no parameters and you get the interactive prompt. Add -Force and it skips straight to removal — what you want when this is driven remotely across several servers rather than typed at a console one at a time.

🖥️ Running It

Interactive — single server

# In an elevated PowerShell session on the target server
.\Remove-VMwareTools.ps1

Read the printed list of registry keys, folders, and services carefully, then type y to proceed.

Unattended — for remote or scripted runs

.\Remove-VMwareTools.ps1 -Force

Across multiple servers with PowerShell remoting

Once you've validated the behaviour interactively on a test box, the same script can be pushed out to a batch of generic servers via Invoke-Command:

$targetServers = @('SERVER01', 'SERVER02', 'SERVER03')
$cred          = Get-Credential   # local or domain admin on the targets

Invoke-Command -ComputerName $targetServers -Credential $cred -ScriptBlock {
    & 'C:\Scripts\Remove-VMwareTools.ps1' -Force
}

🚫 What It Doesn't Touch

To keep the script predictable, it deliberately stays out of two areas:

• Kernel driver binaries under C:\Windows\System32\drivers (the VMware network, SCSI, and display drivers) are left in place. They're harmless once the VM is running on different virtual hardware — Windows simply won't load a driver for a device that isn't present.
• Driver Store packages (visible via pnputil /enum-drivers) are also left alone, for the same reason.

If you want a full hygiene check after migrating off VMware, this is a quick generic sanity check:

driverquery /v | findstr /i vmware

💡 Pro Tips & Best Practices

📦 GitHub Repository