A VCSA patch or upgrade fails with FileNotFoundError: [Errno 2] No such file or directory: …/patching_backup_config.json, and the update microservice log shows HTTP/1.1 403 Forbidden against dl.broadcom.com. The missing-file error is a red herring — staging never completed because the download was forbidden, so VCSA never wrote the file. The actual cause is almost always an expired or unentitled Broadcom download token. Refresh the token, clean up the half-staged state, retry.

Confirm it's the token

SSH into the appliance as root and tail the update microservice log:

tail -n 200 /var/log/vmware/applmgmt/update_microservice.log

You're looking for lines like:

HTTP/1.1 403 Forbidden
ERROR 403: Forbidden

If you see those, it's a token problem — either the token has expired or it isn't entitled for the exact vCenter version and build you're trying to stage. (Optional: cat /storage/core/software-update/stage/stageDir.json to confirm where staging files would have landed.)

Fix it

1. Refresh the Broadcom download token

Generate a fresh token in the Broadcom support portal, and double-check it's entitled for the target version/build. Re-paste it into VAMI's update repository settings.

If online tokens keep giving you grief, skip ahead to the ISO method below — it's often the path of least resistance for one-off upgrades.

2. Clean up the half-staged state

A failed stage leaves debris that will break the next attempt. Start with the gentlest option.

Option A — unstage (try this first):

software-packages unstage

Option B — full reset (only if Option A doesn't clear it, and only with a known-good VCSA backup or snapshot):

service-control --stop applmgmt

rm -rf /storage/core/software-update/updates/*
rm -rf /storage/core/software-update/stage/*
rm -f  /storage/db/patching.db

mv /storage/core/software-packages/staged-configuration.json /storage/core 2>/dev/null
mv /etc/applmgmt/appliance/software_update_state.conf /storage/core 2>/dev/null

service-control --start applmgmt

Deleting /storage/db/patching.db is the bit specific to token-induced failures — Broadcom's own KB calls it out as part of the recovery path before retrying with a valid token.

3. Retry stage & install

In VAMI: https://<vcsa>:5480 → Update → Check Updates → Stage and Install. If you still see 403s in update_microservice.log, the new token is wrong too — go back to step 1.

Fallback: ISO from a datastore

If online repositories keep failing (token, entitlement, network policy), use the offline ISO method instead. Attach the ISO from a datastore, not via the vSphere remote console — Broadcom documents update failures with the same staging-artifact symptoms when the ISO is mounted through remote console.

Worth knowing

  • The missing patching_backup_config.json is always a downstream symptom — VCSA writes that file at the end of a successful stage. If you see this filename in an error, look upstream for the failed download.
  • Capture /var/log/vmware/applmgmt/update_microservice.log and the exact missing-file path before opening a Broadcom support case; those two pieces are what they'll ask for first.

References

  • Broadcom KB — "Updates using online repositories fail" (token / 403 Forbidden / missing patching_backup_config.json)
  • Broadcom KB — "vCenter upgrade fails with missing patching_backup_config.json"
  • Broadcom KB — "Update of vCenter fails — Stage path file doesn't exist / package discrepancy" (cleanup steps)
  • Broadcom KB — "vCenter Server update fails — ISO attached via remote console" (datastore-attach workaround)