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 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 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, click Manage, then open Licensing.
2. Confirm a VCF License Server entry appears in the License Servers table and reports a healthy state.
3. Confirm that VCF Operations and the license server are registered with the VCF Business Services console, shown by a Registered state.
4. If the license server does not appear or reads unhealthy, confirm the management network path between VCF Operations and the appliance, since the license server itself does not reach the internet.
5. Refresh the licensing screen and confirm the license server reports a healthy state.

Moving licensing into its own appliance changes what you check. In earlier releases you looked inside VCF Operations for entitlements, but in 9.1 a dedicated license server appliance holds them and VCF Operations manages its lifecycle. The license server stays inside your environment and does not reach the internet, so the outbound link that matters belongs to VCF Operations. In connected mode, VCF Operations reaches the VCF Business Services console to register and to report usage, while the license server only needs the management network path to VCF Operations. 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. Add the licenses to the license server through the VCF Business Services console, then update them in VCF Operations so they are ready to assign.

1. In the VCF Business Services console, open Licensing, then Licenses, and click Add to VCF Operations.
2. In the Add Licenses to a VCF Operations Instance wizard, select the licenses to add, then the VCF Operations instance and the license server.
3. Review the covered core count and confirm it meets or exceeds your deployed core count.
4. In VCF Operations, open Licensing, then Licenses & Registration, and click Update Licenses.
5. On the Version 9+ tab, confirm the license appears with an active state and its full capacity.

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

Step 6, assign and confirm the primary license on vCenter

Licenses are assigned to vCenter instances in VCF Operations. Assigning a primary license to a vCenter instance automatically licenses the ESX hosts and other components connected to it, so this is the step that makes the fleet compliant.

1. Log in to VCF Operations as an administrator.
2. Click Manage, open Licensing, then Licenses & Registration, and select the Version 9+ tab.
3. In the vCenter Systems table, select each vCenter instance, then click Assign Primary License and click Assign.
4. Confirm the Primary Licenses column shows the assigned license for every vCenter instance.
5. Confirm the covered core count meets or exceeds the deployed core count, with no host left in evaluation for lack of capacity.

Assigning the primary license at the vCenter level matters because every ESX host and connected component inherits its entitlement from that assignment, so you license a whole domain in one action rather than editing individual hosts. If a vCenter instance requires more capacity than the license has left, its extra hosts are added in evaluation mode, and they disconnect once the 90 day host evaluation expires unless you add capacity or assign an override license. Read the covered core count against the deployed core count you recorded during planning, and confirm they match. When you need to license an asset directly, for example an ESX host or a vSAN cluster, assign an override license to it in VCF Operations rather than reaching for a key in the vSphere Client.

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 reports healthy, and your license reads active and in compliance in VCF Operations with the primary license assigned to every vCenter instance. 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[VCF Business Services console] --> B[VCF License Server appliance]
  B --> C[VCF Operations license management]
  C --> D[vCenter primary license]
  D --> E[Hosts and components 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 is deployed automatically with VCF and whose lifecycle VCF Operations manages, sized at 2 vCPU, 4 GB memory and an 8 GB disk. The licenses are stored on the appliance rather than 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 long you have before licensing is enforced. After you deploy or upgrade VCF Operations to 9.1, it runs in evaluation mode for up to 90 days. Register VCF Operations and the license server with the VCF Business Services console and license your environment within that window, since license assignment is blocked once evaluation ends.

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