VCF 5.2 Precheck Shows an Old Version After an Out-of-Band Update

Someone patched ESXi, vCenter or NSX directly instead of through SDDC Manager. Now an upgrade precheck in VMware Cloud Foundation (VCF) 5.2 fails, and the version it quotes is the old one, even though the component is already running the newer build.

The cited sources describe at least two candidate explanations. They are not the only possible ones, and more than one can apply at the same time:

1. Inventory lag. SDDC Manager stores its own record of each component's version, and that record has not caught up yet (KB 324050).
2. Inventory drift outside the BOM. The component's actual version does not fit the bill of materials (BOM) that SDDC Manager expects (KB 453941).

This article shows how to record what you can read, keep the times apart, and see which candidate the evidence supports. Where the evidence does not settle it, the cause stays unresolved. It does not run a sync, a precheck, an upgrade or an API call.

This guide is based on source research only. Nothing in it was run. Version labels such as VC-OLD and VC-NEW are fictional placeholders, not real build numbers.

What Broadcom documents

What the manual sync does

KB 324050 describes a version-synchronisation request that updates the versions "stored in the VCF inventory" for vCenter, ESXi, NSX and VxRail. It can run across the whole system or for one workload domain, and it can be limited to selected product types.

It is an inventory change. It needs authenticated access to SDDC Manager. This article does not reproduce the request, the token step or any command. If an owner chooses to run it, it is their separate change, made from the KB.

Before you start

• Read access to the SDDC Manager UI, including its task panel.
• The exact precheck message, with the component and the version it quotes, and when that precheck ran.
• The actual component version, read from the component itself (for example, the version shown by vCenter for itself, or for a host) by someone with access, with the time you read it. Do not change anything to get it.
• When the out-of-band update finished, from the change record.
• The time zone of each time you record. The daily run is in SDDC Manager's local server time, which may differ from the change record's time zone.

Step 1: record the versions and four separate times

Keep these times apart. A is what was installed when you looked. B is only the version that precheck used at the moment it ran; a current value of B is unknown until a later record shows it. This guide does not name an SDDC Manager screen that lists stored component versions, because the cited KBs do not.

For C, a task counts for this component only if its scope and product filter cover it: the whole system, or the component's domain, with no filter or a filter that includes the product. Keep three things apart for each covering task: that it covered the component, that it finished, and that it succeeded. A task that finished may have failed.

A missing task history, a partial one, or tasks for another domain or product only, leave C unknown for this component. Not seeing a task is not evidence that none ran. KB 324050 says the manual sync's status can be observed in the task panel; it does not say the panel keeps a complete history of the daily automatic runs. So "no covering sync between U and the precheck" can only be stated when D names an owner record that covers that whole period for this component.

Step 2: compare them

Read the rows in order and use the first one that matches.

A stored version that matches the actual one only shows that SDDC Manager's record agrees at that time. It does not certify that the combination is supported by the BOM, or that the upgrade will succeed.

Worked example (fictional)

An administrator patched the vCenter Server of workload domain WLD-02 directly. All times are SDDC Manager local server time (AEDT).

Reading it:

• A is newer than B.
• The task panel shows no covering sync between 14:10 and the 15:00 precheck. Without an owner record that the list is complete for that period, that is not proof that none ran, so C is unknown.
• Inventory lag (KB 324050) remains a candidate, consistent with A being newer than B. It is not established, and it does not exclude a second issue.

What happens next: either the owner repeats the precheck after the next scheduled run, or the owner runs the manual sync from KB 324050 as a recorded change. Afterwards a new B (from that precheck) and C are recorded.

If the new record shows a covering sync that succeeded after 14:10 and a fresh B = VC-NEW from a precheck after it, the lag candidate is resolved. If the precheck still fails, read its error. If it reports a BOM conflict, KB 453941 applies; otherwise the cause stays unresolved and goes to the owner or support.

Two contrasting records (fictional)

Troubleshooting

Acceptance checks

1. U, A, B and C are recorded, each with its own time and time zone.
2. Each sync task in C has its scope, product filter, type (daily or manual, if shown) and state (succeeded, failed, running or not shown) recorded. D names the owner record that shows complete history for the period, or says "not established"; missing or partial history is recorded as unknown, never as "no sync".
3. Unknown, running and failed records are classed before the lag and successful-sync rows. The case is classed as unresolved, not yet readable, failed sync, consistent with inventory lag, or succeeded-sync-without-change. A class is never stated as the only cause.
4. "Consistent with lag" is stated only when D establishes that no covering sync ran. "Not explained by lag alone" is stated only for a covering sync that succeeded plus a fresh B from a later precheck.
5. Waiting for the scheduled sync or a manual sync by the owner is offered only for a lag or unresolved record, as a separate change.
6. B is treated as the version that one precheck used, not the current stored value. After any sync, a new record is made.
7. Nobody concludes that a matching inventory proves the BOM is supported or the upgrade will succeed, and nobody claims a BOM mismatch without a primary record of one.

Risk notes

• The manual sync changes SDDC Manager's inventory. Treat it as a change with an owner, not as a read.
• Out-of-band updates can leave a component outside the BOM. KB 453941 shows prechecks failing for that reason. A sync does not fix that.
• A full BOM upgrade is not a universal repair. KB 453941 gives it as one resolution path for inventory drift. It is a planned upgrade, not a troubleshooting step.
• The steps for older SDDC Manager versions do not apply to 5.2. KB 313147's inventory edits for 5.1 and earlier are excluded here.
• Running a precheck to "see the current value" is not part of this guide. It is the owner's step.

These are source-documented behaviours. Expert review and a lab check are still needed before any change to a VCF environment.

Learning notes

• SDDC Manager keeps its own stored copy of each component's version. KB 324050 documents a daily sync at 0300 local server time by default.
• A precheck that quotes an old version after an out-of-band update is consistent with that copy not having synced yet, but other causes can apply at the same time.
• Keep four times apart: update finished, version observed, precheck run, sync task. Record time zones.
• A sync task only counts if its scope and product filter cover the component.
• An accurate inventory is not proof of a supported combination, and not proof of the precheck's cause.

References

Related articles

• vSphere major upgrade order and interoperability, which covers upgrade sequence, interoperability and go/no-go.