Major Change Alert: VMware Patch Downloads Now Require Tokens

Broadcom has rolled out a significant change that affects all VMware patching workflows: shared public patch URLs are no longer supported. From now on, every environment must use per-customer download tokens for accessing software depots across ESXi, vCenter, VAMI, and Cloud Foundation components.

Let’s break down what’s happening, why it matters, and how to fix your setup.

What’s the Problem?

You’ve probably noticed errors like:

vLCM/VUM: Failed to download VIB(s): HTTP 403
VAMI: “The vCenter Server is not able to reach the specified URL”
vCenter Updates: “Authentication failed,” or patches just don’t appear

These are all symptoms of a deeper change: the old URLs like hostupdate.vmware.com, depot.vmware.com, and vapp-updates.vmware.com are deprecated. Your patching tools are trying to fetch updates from a source that’s effectively gone.

🔍 What Changed?

Broadcom is tightening security and aligning download access with customer entitlements. Instead of a universal patch repository, each customer now gets a personalized download token. This token must be embedded in your depot URLs, or patching simply won’t work.

🛠️ How to Fix It (Step-by-Step)

1. Get Your Token

Log into the Broadcom Support Portal.
Head to the product page for VMware Cloud Foundation or vSphere.
Find the “Generate Download Token” option and create your token.

This token is used to build your custom depot URLs.

2. Update Your Patching Tools

✅ For ESXi Updates via vLCM or VUM:

Go to vSphere Client → Lifecycle Manager → Settings → Patch Setup.
Disable the old URLs.
Add your tokenized URLs in this format:

https://dl.broadcom.com/<Download TOKEN>/PROD/COMP/ESX_HOST/main/vmw-depot-index.xml
https://dl.broadcom.com/<Download TOKEN>/PROD/COMP/ESX_HOST/addon-main/vmw-depot-index.xml
https://dl.broadcom.com/<Download TOKEN>/PROD/COMP/ESX_HOST/iovp-main/vmw-depot-index.xml
https://dl.broadcom.com/<Download TOKEN>/PROD/COMP/ESX_HOST/vmtools-main/vmw-depot-index.xml

Restart the Update Manager service.
Resync and verify that patches are loading again.

✅ For vCenter Updates via VAMI:

Go to https://<vCenterFQDN>:5480, then Update → Settings.
Replace the update URL with something like:

https://dl.broadcom.com/<Download TOKEN>/PROD/COMP/VCENTER/vmw/<buildVersion>

If the URL doesn’t stick, SSH into the VCSA, enter the appliance shell, and use:

update.set --currentURL <YourTokenizedURL>

This overrides any cached value that might be causing problems.

✅ For VMware Cloud Foundation (VCF) Components:

All tools (SDDC Manager, Application Tool, UMDS, etc.) must now use tokenized URLs.
Make sure dl.broadcom.com is reachable through your firewall.
Remove any legacy endpoints or proxies that point to deprecated VMware URLs.

🧨 Common Pitfalls

Some environments require a full reset of the Lifecycle Manager database if syncing fails even after updates.
Make sure you’re not using multiple /PROD/COMP/ entries in the URL—only one is valid.
The VAMI UI might silently revert to the old URL—use CLI commands to enforce your update settings.
Proxy configurations can block dl.broadcom.com. Double-check your outbound firewall rules.

🔧 Quick Checklist

✅	Step
✔️	Generate your Broadcom download token
✔️	Replace all patch/update URLs in vLCM, VAMI, and VCF
✔️	Restart services and trigger sync jobs
✔️	Allowlist `dl.broadcom.com` in your firewall
✔️	Test and verify patch downloads are working again

💬 Final Thoughts

This shift might feel like a slap in the face—especially if your patching pipeline suddenly broke without warning. But now that Broadcom’s taken the tokenized route, there’s no going back.

Get your download token, reconfigure your tools, and keep your patching workflow alive. It’s a bit of a nuisance, but hey—better to fix it now than get caught with unpatched systems in production.

Subscribe to the channel: youtube.be/@AngryAdmin 🔥

🚨Dive into my blog: angrysysops.com

🚨Snapshots 101: a.co/d/fJVHo5v

🌐Connect with us: