You will validate a freshly deployed VCF 9.1 instance from top to bottom and confirm that its licensing is in place. Validation is the point where you prove that SDDC Manager, vCenter, ESX, NSX, VCF Operations, VCF Management Services and the VCF License Server all agree with each other and report a healthy state. Licensing is the point where you attach your subscription so the fleet stays compliant. Both belong at the end of the build, and both are mandatory. Skipping them leaves you with an instance that looks deployed but has never been checked end to end.

Before you start, make sure the management domain is fully deployed, that VCF Operations is reachable, and that the VCF License Server appliance finished its automatic deployment. If any of those pieces is still building, let it finish first. For the license server and management services background, see the earlier guide on how to deploy VCF Management Services and the License Server, and for the operations console itself see how to set up VCF Operations in VCF 9.1.

Prerequisites

Gather these before you begin. Every item below must be true, or the health check and licensing steps will flag a failure you then have to chase down.

Step 1, run the SoS health check from SDDC Manager

Start with the SoS tool on the SDDC Manager appliance. It walks every managed component and reports a color coded result per check.

1. Open an SSH session to the SDDC Manager appliance FQDN and log in as vcf.
2. Confirm no workflow is running, because a concurrent task makes the health check fail its guardrail.
3. Run the command in the block below and enter the vcf_password when prompted.
4. Wait for the run to finish, which takes several minutes on a fresh instance.
5. Read the summary line and note the path to the full report bundle it prints.

sudo /opt/vmware/sddc-support/sos --health-check

A healthy instance shows every test in green. Amber and red results carry a short reason you use in the next step. To capture a full diagnostic bundle at the same time, run the collect command below and keep the zip for your records.

sudo /opt/vmware/sddc-support/sos --collect-all-logs --zip

Run the health check from the SDDC Manager appliance rather than from a jump host, because the SoS tool reaches every managed component over the management network and needs local access to the appliance to gather its results. Each check touches a specific subsystem, so a red result points you straight at the component that needs attention rather than at the instance as a whole. Keep the printed report path handy, since you open that bundle in the next step and reuse it whenever you rerun a single category. If you plan to raise a support case for any failure, attach the zip the collect command produced, because it carries the logs a support engineer asks for first and saves a round trip.

Step 2, review the report and clear failures

Open the report bundle and work through the categories that came back amber or red. Most fresh instance failures fall into a small set of causes.

1. Open the HTML summary inside the report bundle directory the tool printed.
2. Sort the checks by status and start with red, then amber.
3. For a certificate warning, note the component and expiry date for the certificate step later.
4. For a password expiry warning, note the account so you can rotate it in Step 7.
5. For an NTP or DNS check, fix the record or time source, then rerun the single category.
6. Rerun the full health check and confirm the category now returns green.

Run a focused password check with the command below to see expiry status across every account without a full sweep.

sudo /opt/vmware/sddc-support/sos --password-health --domain-name ALL

A red result rarely means the instance is broken. On a fresh build it usually means a supporting service was not ready when the check ran, or a record has not propagated yet. Fix the underlying cause, then rerun only the affected category so you get fast feedback instead of waiting on a full sweep. Certificate and password warnings are the two you carry forward, because both are cleared later in this guide rather than here. Note the exact component name and account name next to each warning, since those names are what you select on the password and certificate screens in the final step. Once a category returns green on a rerun, mark it done and move to the next red item until none remain.

Step 3, validate the fleet in VCF Operations

VCF Operations is the control point for the 9.x fleet, so its inventory has to match reality. Confirm every component is present and collecting.

1. Log in to the VCF Operations UI as an administrator.
2. Open Fleet Management and confirm the management domain and every workload domain are listed.
3. Open Build, then Tasks, and confirm the last deployment tasks show a Completed state.
4. Open Environment, then Inventory, and confirm SDDC Manager, vCenter, ESX hosts and NSX Manager all report a collecting state.
5. Open Administration, then Adapters, and confirm no adapter shows a failed collection.
6. Open the management domain object and confirm its health badge reads healthy.

A component that appears in vCenter but not in the VCF Operations inventory usually means an adapter has not finished its first collection, so give it a few minutes and refresh before you treat it as a fault. Inventory collection scales with host count, so a large management domain takes longer to settle than a small one. Confirm the last collection timestamp is recent on each adapter, because a stale timestamp is a quiet sign that a credential expired or a network path closed. When every object reports a healthy badge and a recent collection, VCF Operations agrees with vCenter and NSX, and you have a fleet view you can trust for the licensing and security checks that follow.

Step 4, confirm the VCF License Server registered

In VCF 9.1 the license server runs as its own appliance rather than inside VCF Operations. Confirm it deployed and connected before you apply any subscription.

1. In the VCF Operations UI, open Administration, then Licensing.
2. Confirm a VCF License Server entry appears and shows a Connected state.
3. Confirm the appliance registered with the Broadcom Business Services Portal, shown by an Online or Registered badge.
4. If the state reads disconnected, open a console to the appliance and confirm its DNS, NTP and outbound HTTPS on port 443 to the portal.
5. Refresh the licensing screen and confirm the state moves to Connected.

Moving licensing into its own appliance changes what you check. In earlier releases you looked inside VCF Operations for entitlements, but in 9.1 the license server holds them and VCF Operations only points at it. A Connected state means two links are healthy at once, the link from VCF Operations to the appliance, and the link from the appliance out to the Broadcom portal. If the appliance sits behind a proxy, confirm the proxy allows the portal host on port 443, because a blocked outbound path is the most common reason registration stalls. You do not deploy this appliance by hand, so if it is missing entirely, return to the management services deployment and confirm that stage completed before you go further.

Step 5, apply the VCF subscription

VCF 9 is subscription only, and a single per core subscription covers vSphere, vSAN, NSX, VCF Operations, VCF Automation and the Kubernetes service. Attach the subscription in VCF Operations so the license server can distribute it.

1. In the VCF Operations Licensing screen, click Add Subscription.
2. Confirm the subscription pulled from the Broadcom portal, or paste the subscription details if prompted.
3. Review the covered core count and confirm it meets or exceeds your deployed core count.
4. Click Apply and wait for the license server to distribute the entitlement.
5. Confirm the subscription row shows an Active state with a valid expiry date.

Values you confirm on this screen are listed below. Check each one before you move on.

Step 6, confirm license assignment in SDDC Manager

Your VCF subscriptions are managed in SDDC Manager, and any vSAN or solution key you assign in the vSphere Client must also appear here. Cross check the licensing page so the two sides agree.

1. Log in to the SDDC Manager UI as an administrator.
2. Open Administration, then Licensing.
3. Confirm the VCF subscription is listed and shows the covered core count.
4. Confirm every host and domain maps to a valid entitlement with no red compliance flag.
5. If you assigned a vSAN key in the vSphere Client, confirm the same key appears on this page.

Keeping the two licensing views in sync matters because SDDC Manager is where compliance is judged for the fleet, while the vSphere Client is where a vSAN or solution key is physically bound to hosts. A key that lives in one place but not the other produces a compliance gap that surfaces during your next upgrade precheck, when you least want a surprise. Read the covered core count on this page against the deployed core count you recorded during planning, and confirm they match. If a domain shows no entitlement, assign it from here rather than editing individual hosts, so the fleet view stays the single source of record for what is licensed.

Step 7, verify backups, passwords and certificates

Close out validation by proving that recovery and security basics are in place. A new instance often ships with default backup targets and short lived credentials, so confirm each one now.

1. In SDDC Manager, open Administration, then Backup, and confirm an SFTP target is configured and reachable.
2. Click Backup Now for the SDDC Manager configuration and confirm the task completes.
3. Open Security, then Password Management, and review the expiry column for every account.
4. For any account flagged in Step 2, click Rotate Password and monitor the task to completion.
5. Open Security, then Certificate Management, and confirm no certificate is expired or near expiry.
6. Record the completed validation as your baseline in VCF Operations so day 2 alerts compare against a known good state.

A backup target you can see is not the same as a backup you have proven, so run one on demand and confirm it completes rather than assuming the schedule works. Password expiry deserves attention on a new instance because the appliances often ship with short lived defaults, and an account that expires unnoticed can hold a lock on the whole instance until you clear it. Rotate anything flagged now while the environment is quiet, not during a change window when a stuck task is far more disruptive. Certificate checks close the loop, since an expired certificate breaks the trust between components and blocks the very workflows you rely on for day 2 operations. With backups proven, passwords current and certificates valid, you have an instance that can recover and stay secure, which is the point of validation.

Verify the deployment

You have a validated, licensed instance when four things are true at once. Confirm each before you declare the build finished.

First, the SoS health check returns every category in green with no amber or red left. Second, VCF Operations lists every domain and every component in a healthy, collecting state with no failed adapter. Third, the VCF License Server reads Connected, and your subscription reads Active and in compliance in both VCF Operations and SDDC Manager. Fourth, a fresh SDDC Manager backup completed, no password or certificate is near expiry, and you have recorded the result as a baseline. When all four hold, the instance is ready for day 2 work such as adding a workload domain, which the earlier guide on how to create a VI workload domain in VCF 9.1 walks through.

Common errors and fixes

Four failures come up often on a fresh VCF 9.1 instance. Each has a direct fix.

flowchart LR
  A[Broadcom Business Services Portal] --> B[VCF License Server appliance]
  B --> C[VCF Operations licensing]
  C --> D[SDDC Manager licensing]
  D --> E[Hosts and domains entitled]

Common questions

Whether validation is mandatory on a lab instance. Treat it as mandatory even in a lab. Validation is how you learn the instance is internally consistent, and a lab that skips it tends to hide problems that surface later during an upgrade.

Where the license server lives in VCF 9.1. It runs as a dedicated appliance that VCF Operations deploys automatically, sized at 2 vCPU, 4 GB memory and three 4 GB disks. Licensing no longer runs inside VCF Operations itself.

Whether you can run the health check while a workflow is active. No. A running workflow trips the concurrency guardrail and the check fails during pre validation. Wait for the task to finish first.

How often to rerun validation. Run the health check after every change window and before every upgrade, and keep the SoS report as a record. A regular cadence turns validation into an early warning rather than a post incident chore.

References

• VMware Cloud Foundation 9.1 documentation on Broadcom TechDocs
• Deploy VCF Management Services and License Server, Broadcom TechDocs
• Managing password rotation in VMware Cloud Foundation 9.x, Broadcom KB 435190
• Health check operations password expiry step, Broadcom KB 423148

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts