Une machine virtuelle Windows peut démarrer sans problème après sa migration de VMware vers Proxmox VE tout en gardant une installation endommagée de VMware Tools. Le souci apparaît quand le désinstalleur échoue, quand Windows Installer ne retrouve plus le paquet d’origine, ou quand plusieurs services et pilotes restent enregistrés alors que la machine ne tourne plus sous VMware.

• Assurez-vous d’avoir une sauvegarde récupérable de la VM avant de commencer.
• La désinstallation classique via Windows Installer reste toujours la première étape.
• Si PowerShell bloque le script, on peut autoriser l’exécution pour la seule session en cours.
• Le nettoyage forcé touche services, dossiers et clés du Registre : il n’est pas garanti sur tous les systèmes.

Contexte : préparer la VM avant de toucher à VMware Tools

Le nettoyage ne doit jamais commencer par la suppression des dossiers ou des clés du Registre. VMware Tools embarque souvent des pilotes réseau, stockage, vidéo, synchronisation horaire ou communication avec l’hyperviseur. Si Windows s’appuie encore sur l’un d’eux, une suppression trop rapide peut couper la connectivité ou empêcher le démarrage. La première sécurité consiste à disposer d’une sauvegarde récupérable de la VM, via Proxmox, un clone éteint ou l’outil de sauvegarde habituel de l’entreprise. Un snapshot peut aider à revenir en arrière sur un changement mineur, mais ne suffit pas comme seule protection dès qu’on touche aux services ou aux pilotes.

Vérifiez aussi l’accès à la console Proxmox avant de commencer : compter uniquement sur le bureau à distance est risqué, puisque l’interface VMXNET3 peut disparaître pendant la suppression de VMware Tools. Si la VM utilise une adresse IP statique, elle reste parfois associée à l’ancien adaptateur et demande une reconfiguration sur la carte VirtIO.

Vérifiez ces points avant de continuer :

1. Une sauvegarde ou un clone récupérable est disponible.
2. La connexion à Windows fonctionne via la console Proxmox.
3. Les pilotes VirtIO nécessaires sont installés.
4. Le disque de démarrage fonctionne avec le pilote configuré dans Proxmox.
5. La nouvelle interface réseau est connectée.
6. QEMU Guest Agent est installé ou prêt à l’être.
7. Un compte administrateur local est connu.

Les pilotes VirtIO assurent la communication avec le matériel paravirtualisé, tandis que QEMU Guest Agent facilite la gestion à distance et la coordination des sauvegardes : les deux jouent un rôle complémentaire, pas interchangeable.

Les faits : tenter d’abord la désinstallation classique

La désinstallation classique de VMware Tools doit toujours être essayée avant tout nettoyage forcé, via « Programmes et fonctionnalités » ou directement avec Windows Installer :

msiexec.exe /x "{CODE-PRODUIT}" /norestart /L*v "C:Tempvmware-tools-uninstall.log"

Le code produit varie selon la version installée : ne le copiez jamais depuis un autre serveur. Le script présenté plus bas détecte automatiquement les entrées correspondantes dans le Registre, sans passer par Win32_Product, une classe WMI connue pour déclencher des réparations MSI involontaires sur chaque paquet installé.

Que faire si PowerShell bloque l’exécution du script

L’erreur la plus fréquente ne vient pas de VMware Tools mais de la politique d’exécution de PowerShell. Windows refuse parfois d’ouvrir un fichier .ps1 si la politique en vigueur l’interdit, ou si le fichier porte la marque de contenu téléchargé depuis Internet.

Ouvrez PowerShell en administrateur, placez-vous dans le dossier du script, et vérifiez la politique actuelle :

Get-ExecutionPolicy -List

Le résultat affiche plusieurs niveaux (MachinePolicy, UserPolicy, Process, CurrentUser, LocalMachine), et c’est leur ordre de priorité qui détermine la politique effective. Pour une modification temporaire et peu intrusive, limitez l’autorisation à la session en cours :

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
.Remove_VMwareTools.ps1

Ce réglage disparaît à la fermeture de la session PowerShell, sans toucher à la configuration globale de l’utilisateur ou du système. Vérifiez tout de même le contenu du script avant de l’autoriser, surtout si Windows l’a marqué comme téléchargé :

Unblock-File .Remove_VMwareTools.ps1
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
.Remove_VMwareTools.ps1

Si Get-ExecutionPolicy -List affiche une valeur sur MachinePolicy ou UserPolicy, elle vient généralement d’une stratégie de groupe. Ces politiques priment sur les changements locaux et relèvent de l’administrateur du domaine : mieux vaut passer par une invocation indépendante plutôt que d’essayer de les contourner :

powershell.exe -NoProfile -ExecutionPolicy Bypass -File ".Remove_VMwareTools.ps1"

Le script complet, avec simulation et nettoyage forcé

Ce script commence toujours par tenter la désinstallation via Windows Installer. Si cette étape échoue, il conserve les journaux et s’arrête sans toucher aux services ni au Registre. La suppression forcée, activée avec -ForceCleanup, doit d’abord être simulée avec -WhatIf pour visualiser les actions prévues sans rien modifier. Enregistrez-le sous Remove_VMwareTools.ps1 :

#Requires -Version 5.1
#Requires -RunAsAdministrator

[CmdletBinding(SupportsShouldProcess = $true)]
param(
    [switch]$ForceCleanup,
    [string]$BaseWorkDir = "C:TempVMwareToolsCleanup"
)

Set-StrictMode -Version Latest
$ErrorActionPreference = "Stop"

$timestamp = Get-Date -Format "yyyyMMdd-HHmmss"
$runDir = Join-Path $BaseWorkDir $timestamp
New-Item -ItemType Directory -Path $runDir -Force | Out-Null
$logFile = Join-Path $runDir "cleanup.log"

function Write-Log($message) {
    $line = "$(Get-Date -Format 'HH:mm:ss') $message"
    Write-Output $line
    Add-Content -Path $logFile -Value $line
}

$uninstallPaths = @(
    'HKLM:SOFTWAREMicrosoftWindowsCurrentVersionUninstall*',
    'HKLM:SOFTWAREWOW6432NodeMicrosoftWindowsCurrentVersionUninstall*'
)
$vmwareEntries = Get-ItemProperty -Path $uninstallPaths -ErrorAction SilentlyContinue |
    Where-Object { $_.DisplayName -like "VMware Tools*" }

if (-not $vmwareEntries) {
    Write-Log "Aucune entree VMware Tools trouvee dans Windows Installer."
}

foreach ($entry in $vmwareEntries) {
    $productCode = $entry.PSChildName
    Write-Log "Desinstallation classique de $($entry.DisplayName) ($productCode)"
    if ($PSCmdlet.ShouldProcess($productCode, "msiexec /x")) {
        $msiLog = Join-Path $runDir "msiexec-$productCode.log"
        $proc = Start-Process msiexec.exe -ArgumentList "/x $productCode /qn /norestart /L*v `"$msiLog`"" -Wait -PassThru
        Write-Log "msiexec pour $productCode termine avec le code $($proc.ExitCode)"
    }
}

if (-not $ForceCleanup) {
    Write-Log "Nettoyage forcé non demande. Fin du script apres la desinstallation standard."
    return
}

$services = @('VMTools', 'VGAuthService', 'VMwarePhysicalDiskHelperService', 'vmvss')
foreach ($svc in $services) {
    $service = Get-Service -Name $svc -ErrorAction SilentlyContinue
    if ($service) {
        Write-Log "Suppression du service residuel $svc"
        if ($PSCmdlet.ShouldProcess($svc, "Stop-Service + sc delete")) {
            Stop-Service -Name $svc -Force -ErrorAction SilentlyContinue
            sc.exe delete $svc | Out-Null
        }
    }
}

$registryKeys = @(
    'HKLM:SOFTWAREVMware, Inc.',
    'HKLM:SOFTWAREWOW6432NodeVMware, Inc.'
)
foreach ($key in $registryKeys) {
    if (Test-Path $key) {
        $backupFile = Join-Path $runDir ("reg-backup-" + ($key -replace '[\, :]', '_') + ".reg")
        Write-Log "Sauvegarde de $key avant suppression"
        reg export $key $backupFile /y | Out-Null
        if ($PSCmdlet.ShouldProcess($key, "Remove-Item -Recurse")) {
            Remove-Item -Path $key -Recurse -Force -ErrorAction SilentlyContinue
        }
    }
}

$folders = @(
    "$env:ProgramFilesVMware",
    "${env:ProgramFiles(x86)}VMware",
    "$env:ProgramDataVMware"
)
foreach ($folder in $folders) {
    if (Test-Path $folder) {
        Write-Log "Suppression du dossier residuel $folder"
        if ($PSCmdlet.ShouldProcess($folder, "Remove-Item -Recurse")) {
            Remove-Item -Path $folder -Recurse -Force -ErrorAction SilentlyContinue
        }
    }
}

Write-Log "Nettoyage force termine. Journal complet dans $logFile"
Write-Log "Redemarrez la machine et verifiez la connectivite reseau via la console Proxmox avant de fermer la session."

Exécutez toujours d’abord une simulation avant d’activer le nettoyage forcé :

.Remove_VMwareTools.ps1 -ForceCleanup -WhatIf

Si les actions affichées correspondent à ce que vous attendez, relancez sans -WhatIf pour appliquer réellement le nettoyage.

Analyse : pourquoi ce script reste prudent

Le script évite volontairement Win32_Product, sauvegarde les clés de Registre avant de les supprimer, journalise chaque action et propose un mode simulation. Il ne touche pas non plus au DriverStore de Windows : les pilotes VMware qui y restent enregistrés n’empêchent généralement pas le fonctionnement de la VM et leur suppression demande un traitement à part avec pnputil, hors du périmètre de ce nettoyage. Cette prudence compte davantage à mesure que les migrations VMware vers Proxmox se multiplient, un mouvement alimenté par la hausse des tarifs de licence post-Broadcom que subissent des entreprises comme Tesco.

Perspectives : un nettoyage récurrent à mesure que les migrations s’accélèrent

Deux ans après le rachat par Broadcom, le marché de la virtualisation reprend la main et de plus en plus d’équipes infrastructure migrent leurs VM vers des alternatives comme Proxmox VE, dont l’argument principal reste souvent la facture. Ce type de nettoyage post-migration va donc devenir une tâche récurrente pour les administrateurs système, bien au-delà des premiers early adopters de Proxmox.

Questions fréquentes

Faut-il désinstaller VMware Tools immédiatement après la migration ?

Non. Il vaut mieux d’abord vérifier que la VM démarre correctement sous Proxmox, que les pilotes VirtIO fonctionnent, et disposer d’une sauvegarde avant de toucher à VMware Tools.

Que faire si la désinstallation classique échoue ?

Le script propose un mode -ForceCleanup qui supprime services, clés de Registre et dossiers résiduels, après simulation obligatoire avec -WhatIf.

Pourquoi éviter Win32_Product pour détecter VMware Tools ?

Cette classe WMI déclenche une vérification, voire une réparation, de chaque paquet MSI installé sur la machine, ce qui peut ralentir le système ou provoquer des effets de bord imprévus.

Le script supprime-t-il aussi les pilotes VMware du DriverStore ?

Non, volontairement. Cette opération demande pnputil et un traitement séparé, car des pilotes orphelins n’empêchent généralement pas le fonctionnement normal de la VM.

Source : RevistaCloud