An Error Occurred While Connecting To Depot | Fix Fast

Guide / By

This “an error occurred while connecting to depot” message most often points to TCP 9084 or DNS failing between an ESXi host and your vCenter FQDN.

When this pop-up shows up during an image compliance check, it can stop a patch window. You start the scan, a host reaches out for image metadata, then the depot call fails and the UI throws the warning.

The upside is that this error is mechanical, not mysterious. If you confirm name resolution and connectivity to the depot port from the ESXi host, you’ll fix many cases.

An Error Occurred While Connecting To Depot

In vSphere Lifecycle Manager, the “depot” is the web location that serves update metadata to an ESXi host during image scanning and remediation. With image-based clusters, hosts often fetch that metadata from a vCenter-hosted repository path that listens on TCP 9084.

Broadcom’s KB for this exact message ties the failure to a blocked 9084 path between the host and vCenter, while a related KB ties the same message to name resolution failures on the ESXi side.

What The Host Is Trying To Reach

On an affected host, /var/run/log/lifecycle.log commonly shows a URL that includes the vCenter FQDN and port 9084, then an index.xml download that times out or fails. You may see vendor “micro-depot” paths inside the URL when the cluster image includes vendor content.

  • Depot URL uses vCenter name — The log lines commonly point at http://:9084/vum/repository/hostupdate/....
  • Failure text varies — You might see or a name resolution failure in the same area of the log.
  • UI symptoms follow — Compliance can fail, remediation can stall, and host image status can switch to unknown.

Fast Triage Before You Change Anything

Sort scope first, then act. It keeps you from chasing the wrong layer.

  • One host fails — Start with that host’s DNS, gateway, and firewall rules.
  • Only remote sites fail — Treat VPN filters and site firewalls as the first suspect.
  • All hosts fail at once — Check vCenter reachability, vCenter DNS records, and vCenter services tied to Lifecycle Manager.

Fixing The Depot Connection Error On ESXi Hosts

Start on one affected host. Once a single host can scan the image again, repeat the same fix across the rest of the cluster.

Test Port 9084 From The ESXi Shell

Broadcom’s KB for this issue calls out TCP 9084 being blocked between the ESXi host and vCenter. The quickest test is a direct TCP connect from the host to the vCenter FQDN.

nc -z  9084
  • Connection succeeds — Move to DNS and name checks, then vCenter service checks.
  • Connection fails or times out — Treat it as routing, firewall, or VPN policy until proven otherwise.

Confirm The Host Is Using The Right Management Path

It’s easy to test from the wrong vmkernel interface when a host has multiple management networks. If you use a dedicated management vmk, confirm that vmk has the right gateway and can reach the vCenter subnet.

  • Check the management gateway — A missing gateway can break east-west access even when the host has internet access via another path.
  • Run a simple ping test — A ping is not a full health check, but it’s a fast way to spot a routing break before you chase ports.

Use The Log To Match The Exact Target

If your vCenter has multiple names, test the same name the host is trying to reach. The error can persist when you test vcenter.local but the log is calling vcenter.site.example.

  • Pull the depot URL from lifecycle.log — Copy the vCenter name and port shown in the failing line.
  • Re-run nc with that name — The goal is to validate the identical path the host is using.

Ports And Firewalls To Verify

For image-based management, the host needs to reach the Lifecycle Manager depot path. Broadcom states that blocking TCP 9084 between the ESXi host and vCenter can trigger this message.

Port rules can be confusing because some Update Manager traffic can appear to flow over 80 or 443, with a reverse proxy forwarding requests to 9084. So 443 working does not guarantee depot access is healthy.

Check What It Tells You Next Move
ESXi → vCenter TCP 9084 The host can reach the depot web service If it fails, fix firewall or routing rules
ESXi → vCenter TCP 443 General vCenter UI/API reachability Keep going; 443 can pass while 9084 is blocked
vCenter → Hosts TCP 902 Host management traffic can pass If it fails, fix edge rules between mgmt networks

Places Where 9084 Gets Dropped

  • Edge firewalls — Rule sets that allow 443 but drop 9084 will break depot access.
  • Site-to-site VPN filters — “Well-known ports only” policies can block 9084 on remote sites.
  • Micro-segmentation rules — East-west filtering between host management VLANs and vCenter can be the only break.
  • Host firewalls — Rare, but a hardened host rule set can block outbound calls on non-standard ports.

Give Your Firewall Owner A Clean Test

If someone else controls the firewall, give them a single, repeatable test instead of a long description. A timestamped nc result plus the vCenter FQDN and port is usually enough to get the rule change done quickly.

  • Share the failing host IP — It helps match the correct source zone.
  • Share the target FQDN and resolved IP — It avoids a rule built for the wrong target.
  • Share the port list reference — Broadcom’s Update Manager port list includes 9084 as the host update web service port.

DNS And Name Resolution Checks

If the host log shows a “Temporary failure in name resolution” error for the vCenter FQDN, Broadcom’s KB says the ESXi host can’t resolve the vCenter name referenced in the depot URL.

Check DNS Settings On The Host

DNS issues can be subtle. A host can resolve public names fine, yet fail the internal vCenter name because of a missing search suffix, split DNS, or a resolver that can’t answer your internal zone.

esxcli network ip dns server list
esxcli network ip dns search list
  • Confirm the resolver IPs — Make sure each listed DNS server is reachable from the host management network.
  • Confirm the search domain — If the depot URL uses a short hostname, the search domain must expand it to the right FQDN.
  • Confirm consistent config — If only a subset of hosts fail, compare their DNS server list against a working host.

Validate The vCenter Name From The ESXi Side

Run a lookup against the same vCenter FQDN shown in the lifecycle log. If the name resolves to the wrong IP, fix DNS before you touch anything else.

  • Use the full vCenter FQDN — Test the same name that appears in the depot URL line.
  • Check for round-robin surprises — If DNS returns multiple IPs, make sure every returned IP is valid for the vCenter service.

Use A Hosts File Mapping As A Stopgap

If you can’t change DNS quickly, you can temporarily map the vCenter name locally on the ESXi host. Broadcom documents hosts file configuration as an alternative when DNS can’t be used.

  • Map vCenter FQDN to the right IP — Add an entry that matches the certificate name used by vCenter.
  • Track the change — Keep a note of which hosts were changed so you can remove the entry once DNS is corrected.

Proxy, Certificates, And Time Sync Checks

Once TCP 9084 and DNS are clean, the remaining failures tend to come from policy or trust issues that interrupt the HTTP request.

Proxy And NAT Rules That Get In The Way

  • Check for forced proxy paths — Transparent proxies can block non-standard ports or rewrite headers in ways ESXi doesn’t like.
  • Bypass internal names — If a proxy is required for outbound traffic, keep internal vCenter traffic out of that path.
  • Watch for NAT hairpins — If hosts reach vCenter through a NAT loop, the depot URL may route out and back in, then fail on port rules.

Certificates And TLS Inspection

Many shops run TLS inspection on outbound traffic. If that inspection lands on your management path, it can break trust between host and vCenter services.

  • Check for SSL interception devices — A device that swaps certificates can break depot calls even when the TCP port is open.
  • Stick to the vCenter FQDN — Name mismatches can trigger certificate validation trouble when services expect a specific host name.

Time Drift And Token Failures

Large clock drift can break authentication tokens and TLS sessions. Confirm NTP is set on vCenter and on each ESXi host, then retry a single-host compliance scan.

  • Check ESXi time and NTP status — Fix any hosts that are off by more than a minute.
  • Check vCenter appliance time — If vCenter time is off, fix that first, then scan again.

When The Issue Comes From vCenter Services

If the host can resolve the vCenter name and connect to TCP 9084, shift the check to vCenter. Hosts pull depot metadata from vCenter’s repository service for Lifecycle Manager and Update Manager.

Test The Depot URL From A Peer System

From a system on the same network as the hosts, try opening the depot URL shown in the host log. You’re checking that the web service responds at all, not trying to download the full depot.

  • Use the exact URL from lifecycle.log — Copy the full path and try a basic HTTP GET.
  • Match timeout symptoms — Broadcom’s log samples show timeouts when depot downloads fail.

Check Storage And Repository Health

Depot metadata can’t be served if vCenter storage is full or the repository can’t read its metadata files. Check free space on the appliance, then clear old ISO or patch files if you’re tight on disk.

  • Confirm free space — Low disk can break services in strange ways.
  • Confirm repository paths exist — If you recently migrated baselines or imported an ISO, confirm the repository location still exists and is readable.

Retest With A Clean, Repeatable Loop

After each change, re-run the checks in the same order so you don’t fool yourself. Start with DNS resolution of the vCenter name on the ESXi host, then run the TCP 9084 test, then run compliance on one host.

After the fix, run compliance twice, then start remediation, and watch lifecycle.log for new errors so you can spot drift early there too.

  • Run a single-host scan — If one host succeeds, scale out.
  • Capture timestamps — If it fails again, pull log lines from the matching time range in /var/run/log/lifecycle.log.

If the pop-up still reads “an error occurred while connecting to depot” after port and DNS checks, the host log nearly always points at the next blocker: a timeout, a name lookup failure, or a depot URL that never answers.