Force removal of VMware Tools, Program Files, and Windows Services

Remove_VMwareTools.ps1

# This script will manually rip out all VMware Tools registry entries and files for Windows 2008-2019
# Tested for 2019, 2016, and probably works on 2012 R2 after the 2016 fixes.

# This function pulls out the common ID used for most of the VMware registry entries along with the ID
# associated with the MSI for VMware Tools.
function Get-VMwareToolsInstallerID {
    foreach ($item in $(Get-ChildItem Registry::HKEY_CLASSES_ROOT\Installer\Products)) {
        If ($item.GetValue('ProductName') -eq 'VMware Tools') {
            return @{
                reg_id = $item.PSChildName;
                msi_id = [Regex]::Match($item.GetValue('ProductIcon'), '(?<={)(.*?)(?=})') | Select-Object -ExpandProperty Value
            }
        }
    }
}

$vmware_tools_ids = Get-VMwareToolsInstallerID

# Targets we can hit with the common registry ID from $vmware_tools_ids.reg_id
$reg_targets = @(
    "Registry::HKEY_CLASSES_ROOT\Installer\Features\",
    "Registry::HKEY_CLASSES_ROOT\Installer\Products\",
    "HKLM:\SOFTWARE\Classes\Installer\Features\",
    "HKLM:\SOFTWARE\Classes\Installer\Products\",
    "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\"
)

$VMware_Tools_Directory = "C:\Program Files\VMware"
$VMware_Common_Directory = "C:\Program Files\Common Files\VMware"

# Create an empty array to hold all the uninstallation targets and compose the entries into the target array
$targets = @()

If ($vmware_tools_ids) {
    foreach ($item in $reg_targets) {
        $targets += $item + $vmware_tools_ids.reg_id
    }
    # Add the MSI installer ID regkey
    $targets += "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{$($vmware_tools_ids.msi_id)}"
}

# This is a bit of a shotgun approach, but if we are at a version less than 2016, add the Uninstaller entries we don't
# try to automatically determine.
If ([Environment]::OSVersion.Version.Major -lt 10) {
    $targets += "HKCR:\CLSID\{D86ADE52-C4D9-4B98-AA0D-9B0C7F1EBBC8}"
    $targets += "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{9709436B-5A41-4946-8BE7-2AA433CAF108}"
    $targets += "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{FE2F6A2C-196E-4210-9C04-2B1BC21F07EF}"
}

# Add the VMware, Inc regkey
If (Test-Path "HKLM:\SOFTWARE\VMware, Inc.") {
    $targets += "HKLM:\SOFTWARE\VMware, Inc."
}

# Add the VMware Tools directory
If(Test-Path $VMware_Tools_Directory) {
    $targets += $VMware_Tools_Directory
}

# Thanks to @Gadgetgeek2000 for pointing out that the script leaves some 500mb of extra artifacts on disk.
# This blob removes those.
If(Test-Path $VMware_Common_Directory) {
    $targets += $VMware_Common_Directory
}

# Create a list of services to stop and remove
$services = Get-Service -DisplayName "VMware*"
$services += Get-Service -DisplayName "GISvc"

# Warn the user about what is about to happen
# Takes only y for an answer, bails otherwise.
Write-Host "The following registry keys, filesystem folders, and services will be deleted:"
If (!$targets -and !$services ) {
    Write-Host "Nothing to do!"
}
Else {
    $targets
    $services
    $user_confirmed = Read-Host "Continue (y/n)"
    If ($user_confirmed -eq "y") {

    # Stop all running VMware Services
    $services | Stop-Service -Confirm:$false

    # Cover for Remove-Service not existing in PowerShell versions < 6.0
    If (Get-Command Remove-Service -errorAction SilentlyContinue) {
        $services | Remove-Service -Confirm:$false
    }
    Else {
        foreach ($s in $services) {
            sc.exe DELETE $($s.Name)
        }
    }

    # Remove all the files that are listed in $targets
    foreach ($item in $targets) {
        If(Test-Path $item) {
            Remove-Item -Path $item -Recurse
        }
    }
    Write-Host "Done. Reboot to complete removal."
    }
    Else {
        Write-Host "Failed to get user confirmation"
    }
}

Hi. Should this script do more of the steps recommended by https://knowledge.broadcom.com/external/article/315629/clean-uninstallation-of-vmware-tools-in.html ?

I notice it recommends to remove C:\ProgramData\VMware\ (a comment above notes that could be too risky, although as you say, the script naively assumes there'll be nothing else in there).

It also suggests deleting a bunch of service Registry keys from CurrentControlSet.

Hi. Should this script do more of the steps recommended by https://knowledge.broadcom.com/external/article/315629/clean-uninstallation-of-vmware-tools-in.html ?

I notice it recommends to remove C:\ProgramData\VMware\ (a comment above notes that could be too risky, although as you say, the script naively assumes there'll be nothing else in there).

It also suggests deleting a bunch of service Registry keys from CurrentControlSet.

I don't think your link is 100% relevant since it's "Product" description is "VMware Desktop Hypervisor" and it mentions VMware Fusion instead of ESXi. Like some of the drivers mentioned there might not exist in ESXi VMs and such.

At least I'd think almost all who use this script would be dealing with ESXi instead of desktop virtualization...?

I honestly wonder why people don't fix up the MSI installer like I posted previously and just uninstall the tools properly.

I honestly wonder why people don't fix up the MSI installer like I posted previously and just uninstall the tools properly.

Not very practical to fix it with hundreds of VMs during the migration.

I honestly wonder why people don't fix up the MSI installer like I posted previously and just uninstall the tools properly.

Not very practical to fix it with hundreds of VMs during the migration.

We're in the middle of a VMware to Hyper-V migration and discovered that VMware Tools version 12 doesn't uninstall correctly in Hyper-V environments, even though it uninstalls fine within VMware.

Thanks to broestls, this script worked perfectly on the systems I tested.

Thanks to mateuszdrab, VMware Tools 12 uninstalls cleanly if the VM_LogStart row in the MSI CustomAction table is dropped.

After evaluating the pros and cons of each solution, we automated the process of dropping the row. The script:

• Locates the VMware Tools MSI by querying HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products
• Identifies the corresponding MSI in C:\Windows\Installer
• Leverages the WindowsInstaller.Installer ComObject to modify the table

If our VMware Tools versions were uniform, or if I had more time, I could have used an MSI transform to achieve the same result.

I honestly wonder why people don't fix up the MSI installer like I posted previously and just uninstall the tools properly.

Not very practical to fix it with hundreds of VMs during the migration.

We're in the middle of a VMware to Hyper-V migration and discovered that VMware Tools version 12 doesn't uninstall correctly in Hyper-V environments, even though it uninstalls fine within VMware.

Thanks to broestls, this script worked perfectly on the systems I tested.

Thanks to mateuszdrab, VMware Tools 12 uninstalls cleanly if the VM_LogStart row in the MSI CustomAction table is dropped.

After evaluating the pros and cons of each solution, we automated the process of dropping the row. The script:

* Locates the VMware Tools MSI by querying HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products

* Identifies the corresponding MSI in C:\Windows\Installer

* Leverages the WindowsInstaller.Installer ComObject to modify the table

If our VMware Tools versions were uniform, or if I had more time, I could have used an MSI transform to achieve the same result.

Why dont you share your script? You got help from here.

I was just looking at the same issue after I migrated from VMware to Hyper-V and I think I found the solution. The MSI installer was throwing an error code 1603 after trying to launch the VM_LogStart action so I:

• grabbed the path of the cached MSI file in C:\Windows\Installer, copied the MSI file
• opened it in Orca and removed all references to VM_LogStart, saved
• placed the installer back into C:\Windows\Installer and re-ran the uninstall action.
• Uninstall went through nicely

@mateuszdrab Thanks for the tip, I managed to remove it by adjusting the msi file.

I was just looking at the same issue after I migrated from VMware to Hyper-V and I think I found the solution. The MSI installer was throwing an error code 1603 after trying to launch the VM_LogStart action so I:

• grabbed the path of the cached MSI file in C:\Windows\Installer, copied the MSI file
• opened it in Orca and removed all references to VM_LogStart, saved
• placed the installer back into C:\Windows\Installer and re-ran the uninstall action.
• Uninstall went through nicely

Thanks @mateuszdrab this worked on a physical system that been set up with Workstation using the physical drive.

we migrate to Hyper-V and vmxnet3 and monitor driver are still existing is there a workaround to delete them with the script?

I was just looking at the same issue after I migrated from VMware to Hyper-V and I think I found the solution. The MSI installer was throwing an error code 1603 after trying to launch the VM_LogStart action so I:

• grabbed the path of the cached MSI file in C:\Windows\Installer, copied the MSI file
• opened it in Orca and removed all references to VM_LogStart, saved
• placed the installer back into C:\Windows\Installer and re-ran the uninstall action.
• Uninstall went through nicely

Thanks @mateuszdrab this worked on a physical system that been set up with Workstation using the physical drive.

Since others haven't provided their code for how they automated the edit of the MSI, here's my mine with borrowed and AI code. I've only tested this twice so far with plans to use it 100+ more times. I'll update if I run into issues.

https://gist.github.com/KGHague/2c562ee88492c1c0c0eac1b3ae0fecd8

Thanks man this worked Well! screw vm-ware!!!!!!!!

I was just looking at the same issue after I migrated from VMware to Hyper-V and I think I found the solution. The MSI installer was throwing an error code 1603 after trying to launch the VM_LogStart action so I:

• grabbed the path of the cached MSI file in C:\Windows\Installer, copied the MSI file
• opened it in Orca and removed all references to VM_LogStart, saved
• placed the installer back into C:\Windows\Installer and re-ran the uninstall action.
• Uninstall went through nicely

Thanks @mateuszdrab this worked on a physical system that been set up with Workstation using the physical drive.

It works perfectly!