Quick Tip - Validating Broadcom Download Token 

As of last month, customers must generate a new download token from the Broadcom Support Portal (BSP) for in-product downloads of VMware software binaries (e.g. updates, security patches using SDDC Manager, vCenter Server, ESXi, etc.). The Broadcom download token must then be appended after the new product download base URI (e.g. https://dl.broadcom.com/TOKEN/...) and this will ensure you will be able to continue to download updates directly or indirectly (via network proxy) from within the products.

Note: For customers that have setup or are using an offline method to retrieve updates, there are no changes in your workflow, this is only for those pulling software update directly from Broadcom.

A Broadcom download token is scoped to a SiteID and depending on your organization you may have one or more SiteIDs and users can generate a unique download token for each SiteID. It is important to understand that a download token itself does not contain an expiration, while you can revoke an existing token, its validity is based on whether a given SiteID has an active entitlement for the particular VMware SKU that you are attempting to download.

Each time a download request is made, the BSP backend will validate whether the token for a given SiteID has an active entitlement for the product download, if it does the download will be allowed and if not, it will fail.

An organization can create as many download tokens as needed and one question that quickly came up was how can you validate a token is still functional, without directly going into the product to test? In fact, I had the same question and knowing that most of the product repos have some sort of metadata file that we can test for connectivity, I figured this would be the quickest way to validate a download token.

Here are three different endpoints in which you can test the validity of a download token:

• SDDC Manager (VCF):
  • https://dl.broadcom.com/${TOKEN}/PROD/COMP/SDDC_MANAGER_VCF/index.v3
• vCenter Server:
  • https://dl.broadcom.com/${TOKEN}/PROD/COMP/VCENTER/vmw/8d167796-34d5-4899-be0a-6daade4005a3/8.0.3.00000/manifest/manifest-latest.xml
• ESXi:
  • https://dl.broadcom.com/${TOKEN}/PROD/COMP/ESX_HOST/main/vmw-depot-index.xml

Here is an example using either cURL or PowerShell to validate the token against an SDDC Manager endpoint:

TOKEN="FILL_ME"
curl https://dl.broadcom.com/${TOKEN}/PROD/COMP/SDDC_MANAGER_VCF/index.v3

$TOKEN="FILL_ME"
Invoke-WebRequest -URI "https://dl.broadcom.com/${TOKEN}/PROD/COMP/SDDC_MANAGER_VCF/index.v3"

Here is an example using either cURL or PowerShell to validate the token against an vCenter Server endpoint:

TOKEN="FILL_ME"
curl https://dl.broadcom.com/${TOKEN}/PROD/COMP/VCENTER/vmw/8d167796-34d5-4899-be0a-6daade4005a3/8.0.3.00000/manifest/manifest-latest.xml

$TOKEN="FILL_ME"
Invoke-WebRequest -URI "https://dl.broadcom.com/${TOKEN}/PROD/COMP/VCENTER/vmw/8d167796-34d5-4899-be0a-6daade4005a3/8.0.3.00000/manifest/manifest-latest.xml"

Here is an example using either cURL or PowerShell to validate the token against an ESXi endpoint:

TOKEN="FILL_ME"
curl https://dl.broadcom.com/${TOKEN}/PROD/COMP/ESX_HOST/main/vmw-depot-index.xml

$TOKEN="FILL_ME"
Invoke-WebRequest -URI "https://dl.broadcom.com/${TOKEN}/PROD/COMP/ESX_HOST/main/vmw-depot-index.xml"

Regardless of the endpoint that you use to test the download token, you should get some output as demonstrated in the example below or you confirm that you get an HTTP 200 response:

If the download token is invalid, you will get the following error: