Hyper-V: VMware Image Customization Is in Progress After VM Migration

The message usually means that VMware guest customization configuration remains inside the Windows operating system after the virtual machine has been moved to Hyper-V.

VMware guest customization can use Windows Sysprep and VMware components to perform tasks such as computer-name configuration, networking changes and other deployment operations. If the customization process was interrupted or the VM was migrated before the process was completely cleaned up, Windows can retain a VMware-related startup entry.

One component associated with this scenario is sysprepDecrypter.exe. If Windows is still configured to launch it during startup, the old VMware customization workflow can continue to appear even though the VM is now running on Hyper-V.

Hyper-V itself is not normally responsible for displaying this VMware-specific message.

There are two different situations and they should be handled differently.

Windows eventually boots

If the message appears briefly and Windows continues to the login screen, investigate the Windows startup configuration. The VM is able to complete its boot process, so the immediate objective is to remove the obsolete VMware customization trigger.

Windows remains on the message

If the VM remains on VMware image customization is in progress ... and never reaches Windows, do not assume that removing one registry entry is sufficient. The VM may have been migrated while VMware guest customization or Windows Sysprep was incomplete.

In that situation, investigate the Sysprep and Windows Panther logs before making changes.

If Windows boots normally, sign in with an account that has local administrative permissions and open Registry Editor.

regedit

Navigate to:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager

Locate the multi-string registry value:

BootExecute

A normal Windows installation commonly contains:

autocheck autochk *

On an affected migrated VM, you may find an additional VMware-related entry such as:

sysprepDecrypter.exe

Before editing the registry, back up the current configuration. This is particularly important when troubleshooting a production server.

In Registry Editor, right-click the Session Manager key and select Export. Save the resulting registry file to an administrator-controlled location.

You can also capture the current value from an elevated Command Prompt:

reg query "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager" /v BootExecute

Keep the output as part of the change record so the original state is documented.

Double-click BootExecute and review every entry. If the VM has permanently moved to Hyper-V and VMware customization is no longer required, remove only the VMware-specific entry.

For example, an affected value may look like:

autocheck autochk *
sysprepDecrypter.exe

Change it to:

autocheck autochk *

Do not delete the complete BootExecute value. Preserve the standard Windows startup entry.

After making the registry change, restart the Windows VM:

Restart-Computer

Watch the Hyper-V console during startup. If the obsolete VMware startup entry caused the message, the VMware customization screen should no longer appear.

After Windows starts, repeat the same operational test that exposed the issue. Confirm that applications, Windows services, DNS, domain connectivity and network communication work as expected.

After the VM is running correctly on Hyper-V, check whether VMware services are still installed:

Get-Service | Where-Object {
    $_.Name -match "VMware" -or
    $_.DisplayName -match "VMware"
}

You can check installed VMware applications without using Win32_Product:

$paths = @(
    "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*",
    "HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*"
)

Get-ItemProperty $paths -ErrorAction SilentlyContinue |
    Where-Object {$_.DisplayName -match "VMware"} |
    Select-Object DisplayName, DisplayVersion, Publisher

This is useful for identifying VMware Tools and other VMware software that may have remained after the migration.

If the VM is permanently hosted on Hyper-V and VMware-specific functionality is no longer required, uninstall VMware Tools through the normal Windows application removal process.

Open:

appwiz.cpl

Locate VMware Tools and complete the uninstall. Restart the VM if Windows requests a restart.

After removal, check Device Manager and Windows Services for obsolete VMware devices or services. Do not manually delete VMware files or services unless you have confirmed that they are no longer required.

Once the VMware customization issue is resolved, validate the VM as a Hyper-V workload.

Check Hyper-V integration services:

Get-Service vmic*

Depending on the Windows version and configuration, services can include:

vmicguestinterface
vmicheartbeat
vmickvpexchange
vmicshutdown
vmictimesync
vmicvmsession
vmicvss

Also verify the Hyper-V virtual network adapter, IP configuration, DNS, domain connectivity, attached disks, application services and Windows Event Viewer.

• Confirm all expected virtual disks are online.
• Verify the Hyper-V virtual network adapter.
• Check IP address, gateway and DNS configuration.
• Verify domain connectivity where applicable.
• Check Device Manager for failed or obsolete devices.
• Confirm application and Windows services are running.
• Review Event Viewer for boot, driver and service errors.
• Restart the VM again and confirm the configuration remains stable.