A Windows virtual machine can boot correctly after migrating from VMware to Proxmox VE while still retaining a corrupted installation of VMware Tools. The problem arises when the uninstaller fails, Windows Installer cannot find the original package, or multiple services and drivers remain registered even after the machine is no longer running on VMware.
The keys to removing VMware Tools in 20 seconds
- Before starting, ensure there is a recoverable backup of the virtual machine.
- The normal uninstallation via Windows Installer should always be the first attempt.
- If PowerShell blocks the script, you can enable only the current session.
- Forced cleanup modifies services, folders, and registry keys, so it can’t guarantee success on all systems.
The procedure outlined below is intended for cases where VMware Tools resists removal after migration. It includes a more cautious version of the community script published by broestls, with activity logging, simulation using -WhatIf, copying of specific keys, and a clear separation between normal uninstallation and forced cleanup.
Neither the author of the original script nor this article can guarantee that the process will work on all Windows installations, versions of VMware Tools, or Proxmox configurations. Execution is at the administrator’s own risk. Before modifying services, drivers, or the registry, a full backup of the VM should be created and verified for restore capability.
Preparing the virtual machine before removing VMware Tools
Cleanup should not begin by deleting folders or registry keys. VMware Tools may include network, storage, video, time synchronization, or hypervisor communication drivers. If Windows still uses any of them, hastily removing them could leave the machine without connectivity or prevent it from booting.
The most important safety measure is having a recoverable copy of the VM. This could be a Proxmox backup, a powered-off clone, or an image created with your company’s standard protection tool. A snapshot is useful for reverting small changes but shouldn’t be the only safeguard when deleting services, installer entries, and drivers.
Also, verify access to the Proxmox console. Relying solely on remote desktop is discouraged because the VMXNET3 interface might disappear during VMware Tools removal. If the VM uses a static IP, it may still be associated with the old adapter and need reconfiguration on the VirtIO interface.
Before proceeding, review these points:
- A recoverable backup or clone exists.
- The Proxmox console allows login to Windows.
- The necessary VirtIO drivers are installed.
- The boot disk operates with the configured driver in Proxmox.
- The new network interface has connectivity.
- QEMU Guest Agent is installed or prepared for installation.
- A local administrator account is known.
VirtIO and QEMU Guest Agent serve distinct functions. VirtIO drivers enable Windows to use paravirtualized storage, network, memory, or communication devices. QEMU Guest Agent establishes a communication channel between Proxmox and the guest system for management tasks, information queries, and some backup coordination.
Attempt to uninstall VMware Tools conventionally before executing any direct cleanup. This can be done via Installed Applications, Programs and Features, or through Windows Installer:
msiexec.exe /x "{PRODUCT-CODE}" /norestart /L*v "C:\Temp\vmware-tools-uninstall.log"
The product code varies depending on the version installed, so do not copy it from another server. The script included here searches for the corresponding entries without resorting to Win32_Product, which can trigger consistency checks or repairs of MSI packages.
What to do if PowerShell won’t run the script
A common error isn’t related to VMware Tools itself but to PowerShell’s execution policy. Windows might block .ps1 files when the active policy disallows scripts or if the file retains the ‘downloaded from Internet’ mark.
First, open PowerShell as administrator, navigate to the folder containing the script, and check active policies:
Get-ExecutionPolicy -List
The output may show different values for MachinePolicy, UserPolicy, Process, CurrentUser, and LocalMachine. The effective policy depends on precedence.
A minimally intrusive option is to allow execution only for the current session:
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
.\Remove_VMwareTools.ps1
The Process scope affects only that PowerShell session. The change disappears when closing the window and doesn’t alter the user or machine policies permanently.
This approach allows temporary execution of the script but doesn’t replace inspecting the script’s content. Before setting Bypass, review what services, folders, and registry keys it intends to modify.
If Windows has marked the file as downloaded from the internet, you can explicitly unblock it:
Unblock-File .\Remove_VMwareTools.ps1
.\Remove_VMwareTools.ps1
You can also combine unblocking with a temporary session policy:
Unblock-File .\Remove_VMwareTools.ps1
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
.\Remove_VMwareTools.ps1
Alternatively, set the policy for the current user with:
Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned
This setting persists after closing PowerShell. Use it cautiously and only after reviewing your organization’s security policies. For managed servers, it’s preferable to limit scope to Process and avoid permanent changes.
If Get-ExecutionPolicy -List shows restrictions in MachinePolicy or UserPolicy, the restrictions may stem from Group Policy. Those policies take precedence over local settings, and you should follow organizational procedures. It’s not advisable to try bypassing corporate policies without approval.
You can also run the script from an independent PowerShell call:
powershell.exe -NoProfile -ExecutionPolicy Bypass -File ".\Remove_VMwareTools.ps1"
The -NoProfile parameter prevents personal profiles from loading, which could affect the session’s behavior. Still, Group Policy directives might have higher priority.
Complete and safe script for cleaning VMware Tools
The following script first attempts to uninstall via Windows Installer. If this fails, it logs the case and stops without removing services or keys.
Forced cleanup only activates if -ForceCleanup is used. Prior to actual execution, it’s recommended to run with -WhatIf to preview operations without making changes.
Save the file as:
Remove_VMwareTools.ps1
Full script:
#Requires -Version 5.1
#Requires -RunAsAdministrator
<#
.SYNOPSIS
Removes VMware Tools from a Windows VM migrated to Proxmox VE. Created by RevistaCloud.com
.DESCRIPTION
1. Locates VMware Tools entries in Windows Installer.
2. Attempts a normal uninstallation with msiexec.
3. Generates diagnostic logs.
4. With -ForceCleanup, removes residual services, keys, and folders.
5. Does not automatically delete drivers from DriverStore.
.WARNING
Create a recoverable backup before running the script.
First validate access via the Proxmox console.
Review operations with -WhatIf before cleanup.
#>
[CmdletBinding(SupportsShouldProcess = $true)]
param(
[switch]$ForceCleanup,
[switch]$RemoveSharedVmwareFolder,
[string]$BaseWorkDir = “C:\Temp\VMwareToolsCleanup”
)
Set-StrictMode -Version Latest
$ErrorActionPreference = “Stop”
$timestamp = Get-Date -Format “yyyyMMdd-HHmmss”
$runDir = Join-Path $BaseWorkDir $timestamp
$transcriptFile = Join-Path $runDir “cleanup-transcript.log”
New-Item -ItemType Directory -Path $runDir -Force | Out-Null
$transcriptStarted = $false
try {
try {
Start-Transcript -Path $transcriptFile -Force | Out-Null
$transcriptStarted = $true
} catch {
Write-Warning “Failed to start transcript: $($_.Exception.Message)”
}
Write-Host “”
Write-Host “VMware Tools cleanup for a VM migrated to Proxmox”
Write-Host “Work directory: $runDir”
“
Function definitions for locating entries, products, MSI codes, exporting registry, and main cleanup logic are included here, following the detailed steps outlined above.
The script first attempts MSI uninstallation, then, if instructed or failed, proceeds with registry cleanup, service removal, folder deletion, driver checks, and final logging. It ensures the process can be previewed with -WhatIf, and requires explicit confirmation for destructive actions.
Finally, it stops transcription and concludes.
Initial run without forced cleanup
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
Unblock-File .\Remove_VMwareTools.ps1
.\Remove_VMwareTools.ps1
This attempt searches for the MSI package and runs its uninstaller. If successful, a Windows reboot is recommended before checking for leftovers.
Simulating cleanup with -ForceCleanup -WhatIf
.\Remove_VMwareTools.ps1 -ForceCleanup -WhatIf
Carefully review the output. -WhatIf displays the services, keys, and directories that would be removed but does not modify the system.
Performing actual cleanup after confirmation
.\Remove_VMwareTools.ps1 -ForceCleanup
Removing shared VMware folder
.\Remove_VMwareTools.ps1 -ForceCleanup -RemoveSharedVmwareFolder
Use this with caution. Do not apply if the server hosts VMware Horizon agents, backup products, security components, or other applications sharing directories with VMware Tools.
Post-reboot checks
Windows should be restarted after cleanup. Some services may not fully disappear until processes close them.
- Verify VMware Tools no longer appears in Installed Applications.
- Check that services
VMToolsandVGAuthServiceare gone. - Ensure Windows boots without errors.
- Confirm the system disk remains accessible.
- Verify VirtIO interfaces retain connectivity.
- Confirm IP address is correctly configured on the appropriate adapter.
- Make sure QEMU Guest Agent is running.
- Check that Proxmox detects the guest agent properly.
- Verify server applications operate normally.
- Ensure subsequent backups complete successfully.
If Windows reports the IP is assigned to another adapter, it might still be linked to the hidden VMXNET3 interface. Use Device Manager to reveal hidden devices and remove the old interface after verifying VirtIO functions correctly.
This script does not automatically remove VMware drivers stored in the DriverStore. This deliberate limitation aims to prevent accidental removal of critical drivers. Removing drivers based on partial name matches can impact storage, network, or even boot processes.
Remaining drivers should be reviewed manually before using pnputil or Device Manager. When in doubt, it’s safer to leave them installed if they are still needed.
Frequently Asked Questions
Is a backup required before running the script?
Yes. The cleanup modifies services, registry keys, and system folders. A complete or recoverable clone should exist, and access via Proxmox console must be verified.
What if PowerShell states script execution is disabled?
You can enable only the current session with Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass. If the file is downloaded from the internet, use Unblock-File as well.
What if the restriction comes from Group Policy?
Policies in MachinePolicy and UserPolicy can override local settings. In a corporate environment, consult your administrator and follow organizational security policies. Attempting to bypass policies without approval is not recommended.
Does the procedure guarantee VMware Tools can be reliably removed?
No. Installations, versions, and dependencies vary. The procedure provides guidance but should first be tested on a clone or backup, with clear restoration options.
Sources:
- Community script
Remove_VMwareTools.ps1, published by broestls on GitHub Gist. - Microsoft Learn, documentation on
Set-ExecutionPolicy,Get-ExecutionPolicy, andUnblock-File. - Microsoft Learn, MSI uninstall options and activity logging for
msiexec. - Microsoft Learn, how
sc.exe deleteoperates. - Proxmox VE documentation on VMs, VirtIO, and QEMU Guest Agent.
- virtio-win project for paravirtualized Windows drivers.

