Home / Infrastructure Migration / How to Fix VMware Tools Still Pointing to the Old Update Repository After Migration

Infrastructure Migration

How to Fix VMware Tools Still Pointing to the Old Update Repository After Migration

Fix VMware Tools updates still using the old repository after migration by checking productLocker paths, host profiles, lifecycle settings, and stale ESXi configuration.

Published: Nov 1, 20259 min readBy FixWikiHub Editorial Team

Abstract illustration for infrastructure migration troubleshooting guides.

Introduction

A virtualization migration can move shared VMware Tools content or update repositories into the new environment while ESXi hosts and guest update workflows still reference the old one. Guest tools upgrades fail, one cluster uses the new repository while another still pulls from the retired datastore, or updates break only after the previous source is removed because productLocker paths, host profiles, and lifecycle settings often persist beyond the platform cutover.

This issue frequently occurs during vSphere upgrades, datastore migrations, or when consolidating multiple vCenter environments. The VMware Tools bundles may exist in the new location, but ESXi hosts continue looking in the old location due to stale productLocker configuration. This creates inconsistent guest tools versions across the environment and can cause VM functionality issues like copy-paste, drag-and-drop, and automatic resizing to fail.

Treat this as an update-source problem instead of a generic VMware Tools issue. Start by checking which repository path or shared tools location an affected host actually uses for guest tools updates, because migrations often validate the new datastore or content library while existing hosts continue following older configuration.

Symptoms

VMware Tools updates still use the old repository after migration
Guest tools upgrades fail only after the old datastore or source is removed
One ESXi cluster upgrades correctly while another still uses the previous path
vCenter looks healthy, but hosts cannot locate current tools packages
Newly provisioned hosts work while older ones still point to the retired repository
The issue started after moving vSphere storage, shared content, or lifecycle infrastructure
Manual VMware Tools upgrade from vCenter returns "VMware Tools not found" or similar error
/store/packages or /productLocker paths show outdated datastore references
VM console shows "VMware Tools is not installed" even after multiple upgrade attempts
Host profiles show compliance violations related to productLocker path

Common Causes

ESXi productLocker configuration still references the old datastore or repository path
Host profiles or automation templates keep applying the previous VMware Tools source
Lifecycle Manager or cluster settings were updated in one cluster but not another
Shared storage or content library aliases still resolve to the retired source
One host image or template was migrated while older hosts retained legacy settings
Validation confirmed the new repository existed but did not verify what source live hosts actually used
The productLocker symlink points to an old or unmounted datastore
vSphere Lifecycle Manager images were created without the updated tools bundle
Host remediation workflows skip productLocker updates
The old datastore was unmounted before updating host configuration

Step-by-Step Fix

Step 1: Identify Current ProductLocker Path on Affected Host

Capture one affected host and record the configured VMware Tools source, shared repository path, and recent update behavior. The runtime update path determines where tools packages are fetched.

Connect to ESXi host via SSH: ```bash # Check current productLocker path esxcli system settings advanced list -o /UserVars/ProductLockerLocation

# Or check the symlink ls -la /locker/packages/

# Check what's in the current productLocker ls -la /productLocker/ ```

Via PowerCLI: ```powershell # Connect to vCenter Connect-VIServer vcenter.example.com

# Get productLocker location for all hosts Get-VMHost | ForEach-Object { $hostView = $_ | Get-View $productLocker = $hostView.Config.ProductLockerLocation [PSCustomObject]@{ Host = $_.Name ProductLocker = $productLocker } } | Format-Table -AutoSize ```

Step 2: Compare with Expected Post-Migration Design

Compare that active source with the intended post-migration vSphere design. One stale productLocker path or host profile can keep an entire cluster tied to the retired repository.

Expected output should show the new datastore: ``/datastore-new/vmwareTools/ # Correct

Problematic output shows old datastore: ``/vmfs/volumes/old-datastore/VMwareTools/ # Incorrect - old location

Step 3: Review Host Configuration and Profiles

Review host configuration, host profiles, lifecycle settings, shared datastore mappings, and automation templates for references to the old repository. VMware Tools delivery often spans both cluster policy and host-level settings.

Check if host profile applies productLocker: ```powershell # Get host profile reference Get-VMHostProfile | Select-Object Name, @{N='ProductLocker';E={$_.ExtensionData.Config.ApplyProfile.UserProfile.ProductLockerLocation}}

# Check host profile compliance Get-VMHost -Name "esxi-01.example.com" | Test-VMHostProfileCompliance ```

Check Lifecycle Manager settings: Navigate in vCenter: Menu > Lifecycle Manager > Settings > Depot Settings

Verify the VMware Tools depot URL points to the new location.

Step 4: Check Each Cluster Separately

Check each cluster, host image, and provisioning path separately if behavior differs. Migrations often fix one vSphere segment while another still uses the previous source.

powershell

# Compare productLocker across all hosts
Get-Cluster | ForEach-Object {
    $cluster = $_.Name
    Get-VMHost -Location $_ | ForEach-Object {
        $esxcli = Get-EsxCli -VMHost $_
        [PSCustomObject]@{
            Cluster = $cluster
            Host = $_.Name
            ProductLocker = $esxcli.system.settings.advanced.list('/UserVars/ProductLockerLocation').StringValue
        }
    }
} | Format-Table -AutoSize

Step 5: Update ProductLocker Configuration

Update the authoritative VMware Tools source configuration so affected hosts use the intended repository. Copying the tools packages to a new location alone does not retarget already configured hosts.

Via ESXi CLI (per host): ```bash # Set new productLocker location esxcli system settings advanced set -o /UserVars/ProductLockerLocation -s "/vmfs/volumes/new-datastore/VMwareTools"

# Verify the change esxcli system settings advanced list -o /UserVars/ProductLockerLocation

# Recreate the symlink if needed rm /productLocker ln -s /vmfs/volumes/new-datastore/VMwareTools /productLocker ```

Via PowerCLI (bulk update): ```powershell # Update all hosts in a cluster $newLockerPath = "[new-datastore] VMwareTools"

Get-Cluster "Production" | Get-VMHost | ForEach-Object { $vmhost = $_ $esxcli = Get-EsxCli -VMHost $vmhost -V2 $esxcli.system.settings.advanced.set.Invoke(@{ option = "/UserVars/ProductLockerLocation" stringvalue = "/vmfs/volumes/new-datastore/VMwareTools" }) Write-Host "Updated productLocker on $($vmhost.Name)" } ```

1.Via Host Profile:
2.Edit the host profile
3.Navigate to Advanced Configuration Settings > UserVars > ProductLockerLocation
4.Update the path to the new datastore location
5.Apply the profile to all affected hosts

Step 6: Verify VMware Tools Bundle Exists

Ensure the VMware Tools packages are present in the new location:

```bash # Check the new datastore has tools ls -la /vmfs/volumes/new-datastore/VMwareTools/

# Should see folders like: # floppies/ # vmtools/ # index.xml ```

If the bundle is missing, copy from vCenter or download fresh:

bash

# Copy from working host or re-extract
cp -r /vmfs/volumes/old-datastore/VMwareTools /vmfs/volumes/new-datastore/

Step 7: Test VMware Tools Upgrade

Trigger a controlled guest tools upgrade and confirm the host reads packages from the intended repository. A visible tools bundle does not prove live update workflows switched over.

1.From vCenter Client:
2.Right-click a test VM
3.Select Guest OS > Upgrade VMware Tools
4.Monitor for successful installation

Via PowerCLI: ```powershell # Get a test VM and upgrade tools $vm = Get-VM -Name "test-vm-01" Update-Tools -VM $vm -Verbose

# Check the VM's tools status $vm | Select-Object Name, @{N='ToolsStatus';E={$_.ExtensionData.Guest.ToolsStatus}}, @{N='ToolsVersion';E={$_.ExtensionData.Guest.ToolsVersion}} ```

Step 8: Verify Old Repository No Longer Used

Verify the old repository no longer receives requests from migrated hosts. Split update sourcing can remain hidden while both locations are accessible.

```bash # Check if old datastore still has active connections esxcli storage filesystem list

# Monitor for I/O on old datastore (run during upgrade attempt) esxcli storage filesystem stats -l

# Check VMFS volume UUID matches expected new datastore vmkfstools -P /vmfs/volumes/old-datastore/ ```

Step 9: Clean Up Old References

After confirming the fix works:

```powershell # Remove old datastore from hosts (if appropriate) Get-VMHost | Remove-Datastore -Datastore "old-datastore" -Confirm:$false

# Update any remaining host profiles or automation # Check vCenter settings for deprecated depot references ```

Verification

Confirm the fix by verifying:

1.Host configuration check: All ESXi hosts show the new productLocker path
2.```powershell
3.Get-VMHost | ForEach-Object { $_ | Get-EsxCli | Select-Object @{N='Host';E={$_.VMHost.Name}}, @{N='ProductLocker';E={$_.system.settings.advanced.list('/UserVars/ProductLockerLocation').StringValue}} }
4.`
5.VMware Tools upgrade test: At least one VM per cluster can successfully upgrade tools
6.No errors in host logs: Check /var/log/hostd.log for tools-related errors
7.Symlink verification: /productLocker symlink points to the new location

bash

ls -la /productLocker
# Should show: /productLocker -> /vmfs/volumes/new-datastore/VMwareTools

Prevention

To prevent this issue in future migrations:

1.Inventory all productLocker references before migration. Document each host's current settings and expected post-migration value.
2.Use vSphere Lifecycle Manager for consistent image management across clusters. Create base images with the correct tools bundle included.
3.Implement host profile compliance checking that alerts when productLocker drifts from expected value:
4.```powershell
5.# Create a compliance check script
6.$expectedLocker = "/vmfs/volumes/new-datastore/VMwareTools"
7.Get-VMHost | ForEach-Object {
8.$esxcli = Get-EsxCli -VMHost $_
9.$actualLocker = $esxcli.system.settings.advanced.list('/UserVars/ProductLockerLocation').StringValue
10.if ($actualLocker -ne $expectedLocker) {
11.Write-Warning "$($_.Name) has incorrect productLocker: $actualLocker"
12.}
13.}
14.`
15.Update host profiles proactively during migration planning, not after the fact.
16.Test VMware Tools upgrades on representative VMs from each cluster after migration.
17.Document the productLocker dependency in your vSphere architecture documentation, including the datastore it relies on.
18.Use PowerCLI or vRO workflows to standardize productLocker configuration across the environment after any infrastructure changes.
19.Keep the old repository available temporarily during migration but add monitoring to alert on any access attempts after the cutover date.

[WordPress troubleshooting: Fix CloudFormation Permission Denied - C](fix-cloudformation-permission-denied)
[Technical troubleshooting: Fix Cloud Migration Data Transfer Incomplete Issue](cloud-migration-data-transfer-incomplete)
[Fix Database Migration Schema Lock Timeout in Infrastructure Migration](database-migration-schema-lock-timeout)
[Fix DNS Cutover Propagation Delay Issue in Infrastructure Migration](dns-cutover-propagation-delay)
[How to Fix Ansible Automation Controller Still Running Jobs Against the Old Execution Environment After Migration](fix-ansible-automation-controller-still-running-jobs-against-old-execution-environment-after-migration)

Was this guide helpful?

Related search paths

People also search for

If the symptom is close but not identical, these search paths usually surface the right neighboring fixes faster than scrolling the full archive.

VMware Tools Still Pointing to the Old Update Repository VMware Tools Still Pointing to the Old Update Repository Infrastructure Migration VMware Tools Still Pointing to the Old Update Repository troubleshooting VMware Tools Still Pointing to the Old Update Repository fix Fix VMware Tools updates still using the old repository after migration by checking productLocker paths, host profiles, lifecycle settings, and stale ESXi configuration Infrastructure Migration Fix VMware Tools updates still using the old repository after migration by checking productLocker paths, host profiles, lifecycle settings, and stale ESXi configuration

Explore Related Topics

Browse Guides from Other Categories

Discover troubleshooting guides from related categories to expand your knowledge.

FAQ

Infrastructure Migration Troubleshooting FAQs

Common questions about troubleshooting and preventing similar issues

How do I know if this infrastructure-migration troubleshooting guide applies to my situation?

This guide is designed for infrastructure-migration issues. If you're experiencing similar symptoms described in the article, follow the step-by-step instructions. Start with the most common causes and work through the diagnostic process.

Is it safe to follow these infrastructure-migration troubleshooting steps?

Yes, all steps are designed to be safe and non-destructive. We recommend creating backups before making significant changes and testing each step before proceeding to the next.

How long does it typically take to resolve this type of infrastructure-migration issue?

Most infrastructure-migration issues can be resolved within 30 minutes to 2 hours, depending on the complexity and root cause. Follow the troubleshooting flow to identify and fix the problem efficiently.

How can I prevent this infrastructure-migration issue from happening again?

Regular maintenance, monitoring, and following best practices for infrastructure-migration configuration can help prevent recurrence. Consider implementing automated checks and alerts for early detection.

Written by

FixWikiHub Editorial Team

Our editorial team consists of experienced DevOps engineers, systems administrators, and cloud architects with hands-on experience in production environments across AWS, Azure, GCP, and on-premises infrastructure.

Every guide undergoes technical review for accuracy and is updated when software versions, commands, or best practices change.

Last updated: Nov 1, 2025

About our team

Important Notice

Disclaimer & Safety Guidelines

The troubleshooting steps in this guide are provided for educational and informational purposes. Before applying any changes to production systems:

Test in a staging environment first — Always verify commands and configurations in a non-production environment before deploying to live systems.
Create backups — Ensure you have current backups of databases, configurations, and critical files before making changes.
Understand the impact — Review how each step may affect your specific environment, dependencies, and users.
Consult official documentation — This guide supplements, but does not replace, official vendor documentation and best practices.

FixWikiHub is not responsible for any damages arising from the use of this content. See our Terms of Use for more information.

Resources

Official Documentation & Further Reading

For authoritative information, consult the official documentation for the technologies discussed in this guide. Our troubleshooting content supplements, but does not replace, vendor documentation.

AWS Documentation — Official Amazon Web Services guides and API references
Kubernetes Documentation — Official Kubernetes documentation
Nginx Documentation — Official Nginx web server documentation
Apache Documentation — Official Apache HTTP Server documentation
Docker Documentation — Official Docker container documentation