Prerequisites — Gate Before Any Workbook Inputs

This list mirrors the Prerequisite Checklist sheet of the official workbook. If any item is RED for your environment, fix it before spending a single meeting on the rest of the workbook — every later answer depends on these.

Authoritative source: the Broadcom VCF 9.1 Planning and Preparation doc set (the workbook’s TechDocs companion). Sections below link the specific pages where they exist.

When is each item needed?

Not everything here blocks bring-up. Every section below — and every row of the planning templates, in their When needed column — carries one of these four markers, using the same words in both places so a filled template can be checked straight against this doc:

The bring-up gate, at a glance — the subset that must be green before the Installer starts:

• Management-domain hardware — host count/spec, vSAN disks with no existing partitions, single hardware vendor
• VLANs + MTU — every traffic type, jumbo where required (overlay ≥ 1600)
• Host Overlay TEP addressing — static IP pool (recommended) or DHCP
• BGP / ECMP to the ToRs — Centralized connectivity only
• DNS — forward A and reverse PTR for every bring-up FQDN, lowercase, each resolving to a unique unassigned IP
• NTP — two sources, reachable and in sync
• Binaries — depot decision made (online / offline / manual transfer), credentials in hand, SDDC Manager ISO downloaded
• Jump host — routed access + OVF Tool
• Active Directory — reachable, accounts and groups pre-created
• Public URLs / proxy allowlist — if anything is online

Everything else in this document (workload-domain hardware, SMTP, the Certificate Authority, the SFTP backup target, Avi, vSphere Supervisor, fleet SSO) is Day-N: plan it now, but it will not hold up bring-up.

Fillable planning templates (download)

Blank CSV sheets to capture the prereq plan, then transfer into the P&P workbook or Coscia’s planner. Each opens in Excel; the IP/DNS template’s Intake ID column maps back to workbook-cell-mapping.md (the other templates reference intake IDs in their notes where relevant).

Every template carries a When needed column using the same four markers as this document (above) — filter or sort on it to see exactly what must be ready before the Installer runs, and hand the rest to the teams that own it without holding up bring-up.

The IP/VLAN sheets hand off in a fixed order:

1. Network team fills the VLAN / subnet plan — VLANs, subnets, gateways, MTU, and the usable range inside each subnet.
2. Architect fills the IP allocation + DNS plan, assigning each FQDN + IP from those ranges (if the organization runs a central IPAM, request the addresses there instead of self-picking — the architect still compiles the sheet).
3. AD/DNS team creates the forward A and reverse PTR records from the filled IP/DNS plan.

• IP allocation + DNS (A/PTR) — per-appliance FQDN / IP, assigned by the architect from the network team’s subnets in the VLAN plan (create both forward A and reverse PTR); duplicate the block per workload domain, add AZ2 hosts if stretched
• VLAN / subnet plan — VLAN, subnet, gateway, MTU + minimum IP count per traffic type
• NTP / AD / CA — NTP sources, AD domain/accounts/groups, CA + cert template
• BGP peering — Edge/ToR AS, peer IPs, BFD (MD5 optional)
• Firewall request — deployment-critical flows (source / destination / port / purpose) for the security team; see 07-firewall-ports.md

Data hygiene: these are blank templates. A filled copy holds real, sensitive data (IPs, DNS names, AS numbers) — store it in a secure location, not in a public or shared repository.

Hardware

Management Domain

When needed: Bring-up. The Installer validates the hosts it is given.

Two easy-to-miss gate checks: disks intended for vSAN must have no existing partitions (the workbook repeats this on every storage row — a classic bring-up validation failure), and all management-domain hosts must come from a single hardware vendor (Preparing ESX Hosts for VCF or vSphere Foundation).

9.1 management footprint is bigger. Even with most optional fleet components excluded, the management domain runs ~12 appliances / ~120 vCPU, because 9.1 deploys a baseline VCF services runtime (3 control + 3 worker nodes) alongside vCenter, the 3-node NSX Manager cluster and SDDC Manager. It grows further with VCF Operations, VCF Automation, Log Management and the License Server. Don’t reuse a VCF 4.x/5.x host spec — resize on the Management Domain Sizing sheet against the components you’re actually deploying.

Workload Domain

When needed: Day-N. Workload domains are built after bring-up (deployment plan E9) — but order the hardware on the same lead time as the management hosts.

Same shape as Management Domain. Minimum 3 hosts, 4+ recommended for prod. VI workload domains support up to 64 pNICs per host.

TechDocs: Preparing ESX Hosts for VCF or vSphere Foundation covers the ESX install + basic host configuration this gate expects. The hardware minimums themselves (all pNICs ≥ 10 GbE, vSAN hosts certified on the compatibility guide) come from the workbook’s Prerequisite Checklist, not that page.

Network

Source: the workbook’s Prerequisite Checklist → Network Requirements block — every row above mirrors it except the VLAN and load-balancer rows, which are this guide’s additions. TechDocs 9.1 links inline where a page exists; the ECMP and stretched wording has no standalone TechDocs page and is anchored on the workbook itself.

Avi Load Balancer (only if in scope)

When needed: Day-N (if in scope). Nothing here blocks bring-up.

Needed when Avi is the chosen load balancer for any of these: vSphere Supervisor on a workload domain (then the controller cluster must exist before activation — but Supervisor also runs without Avi, via the NSX / VPC networking paths’ built-in load balancer or the Foundation Load Balancer), optionally in front of VCF Automation (never required — both the single-node and HA models ship a built-in L4 load balancer that serves the cluster VIP; Avi in front is a post-deployment addition for SSL termination / keeping user access off the management network), or tenant/workload load balancing. Deployed Day-2 from VCF Operations (lifecycle-managed), with the served domain’s vCenter and NSX already configured. Per the Avi-for-VCF 9.1 requirements, for Supervisor use the controller cluster must be deployed before Supervisor activation.

Controllers are central, Service Engines are local. The Avi controllers always run in the management domain — whichever domain they serve, including a Supervisor on a workload domain. That is the same pattern as a workload domain’s vCenter and NSX Managers, which also run in the management domain (04-sizing.md’s workload-domain repeater). Only the Service Engine VMs are distributed: they run per cluster, in the workload domain.

A controller set is scoped to the NSX instance, not the workload domain: workload domains that share an NSX instance share one controller set; a workload domain with its own NSX instance gets its own set. Count controller sets by NSX instance, and Service Engines by cluster.

Prepare up front:

• 4 IPs on the management domain’s VM Management network, per controller set (so per NSX instance — multiply if the fleet runs more than one): 3 controller nodes + the cluster VIP.
• One DNS record per set — the cluster FQDN, with A + PTR, resolving to the cluster VIP, and it must exist before you start the deploy (field-confirmed 2026-07-22). Reserve four addresses but expect to type three: the wizard takes Node 1/2/3 IP Address, then under “Enter the VIP for cluster access” offers only Cluster FQDN and Cluster Name — the VIP address itself is not entered here. The VIP is reached through the FQDN, which is why the A record has to exist up front. Keep the VIP in the IP plan regardless: it is a real address that must be reserved and excluded from DHCP, it just is not typed into this wizard. The 3 controller nodes are IP-only: the workbook’s Avi section asks for them as plain IP fields and nothing resolves them by name, so don’t ask the AD/DNS team for records that nothing consumes (01-network-dns-plan.md DNS table, intake E16, and workbook-cell-mapping.md all say the same).
• A Cluster Name as well as the cluster FQDN — a separate field, and the two are not interchangeable. Decide both up front rather than inventing one at the wizard.
• Controller size: Small / Large / XLarge (the deploy wizard’s tiers). Size it in 04-sizing.md — note the workbook’s Avi disk figures diverge from the NSX ALB controller ladder.
• Two strong passwords (password manager, owners in intake F11): the controller admin and the VCF Ops admin accounts — the wizard asks for both, on the same screen, so the VCF Operations admin credential has to be to hand at Avi deploy time, not just the new Avi one. Avi’s rule, verbatim from the field tooltip: at least one lowercase, one uppercase, one digit, one special character (!@#$%^&*()~) and at least 15 characters.
• Avi binaries in the depot — 32.1.1 or higher must be available from the (online or offline) depot before VCF Operations can deploy the controller (see 09-binary-depot.md).
• A local content library in the target vCenter for the Service Engine images, and a Service Engine management network (dedicated VLAN or overlay segment; SE management IPs via DHCP or a static IP pool in the controller). Service Engines are always present per cluster — every cluster Avi serves runs its own, with a minimum of 2 for HA, so budget their footprint and management IPs per cluster in the workload domain, not once per fleet. The VIP source depends on the networking path (VDS: VIP/data network + IPAM profile; VPC: the VPC external IP blocks).
• Firewall: admin access to the controller UI/API (443) and the Service Engine ↔ controller secure channel — see 07-firewall-ports.md §E.
• A passphrase for the controller’s configuration backups (separate from the admin/VCF Ops admin passwords) — treat it like the SFTP backup encryption passphrase: chosen up front, stored in a password manager, with a named owner. It is required to restore, and nothing on the VCF side asks for it.
• A License Hub decision — the controller must be pointed at either Cloud Licensing or an on-prem License Hub before it reports usable licences; see 15-license-hub.md.

For the deploy wizard fields, the controller’s own first-login setup, the full licensing chain, and known gotchas, see 14-avi-load-balancer.md.

License Hub (only if vDefend or Avi is in scope)

When needed: Day-N (if in scope). Nothing here blocks bring-up.

License Hub provides “centralized license management and reporting for VMware vDefend and VMware Avi subscription license files” — it replaces the traditional 25-character license keys with digitally signed subscription license files. Needed only when vDefend or Avi is in scope; plain VCF without either does not need it.

License Hub is not the License Server — and both exist. The License Server is deployed automatically at bring-up, is tied to VCF Operations, and licenses the VCF fleet (deployment plan story 5.4). License Hub is a separate appliance, deployed Day-N, licensing vDefend + Avi. They coexist — a fleet running Avi has both. Two similar names, two unrelated appliances: don’t plan one and assume it covers the other.

Prepare up front:

• Decide the deploy path by version — the mechanics differ. License Hub 2.0 (current, GA 2026-08-05) deploys as one standalone OVA (~11 GB, downloaded from the VMware Avi Load Balancer product page, not vDefend SSP); 5.1.2 deploys from the separate SSP Installer plus a .tar package as a 3-VM instance. Confirm which version applies before planning IPs/FQDNs, since the pool/FQDN shapes are not the same between them.
• IP/FQDN plan, immutable after deployment either way. 2.0 needs an appliance FQDN/IP plus a 2-address Kafka pool and a non-routable internal cluster CIDR (≥512 addresses); 5.1.2 needs ~9 IPs across node + service pools plus two FQDNs (Instance, Messaging). See 15-license-hub.md for the exact field-by-field shape.
• Registration mode — Connected or Disconnected, decided at first login, tied to the depot decision (intake G1). Connected needs the endpoint portal.pulse.broadcom.com (Avi Cloud Console — not on the Public URLs list) reachable from an administrator’s browser; disconnected is a recurring manual file-exchange loop, including a six-monthly licence re-import, forever, for air-gapped sites.
• A Broadcom customer account holder identified — an entitlement question, not the same person as the vCenter administrator. Either mode needs someone who can act on it.
• NSX firewall exclusion planning — if License Hub VMs sit in an NSX overlay/VLAN segment with security enabled, they need a firewall exclusion entry; raise this with whoever owns DFW policy before deploying.

For the full deploy-wizard field tables (both 2.0 and 5.1.2), the post-deploy registration/licensing chain, and field-verified gotchas (including a firstboot failure mode in 2.0), see 15-license-hub.md.

vSphere Supervisor (only if in scope)

When needed: Day-N (if in scope).

Nothing here is needed at bring-up — the Supervisor is enabled per workload domain, Day-N (intake H5, deployment plan E9). But activation asks for all of it at once, and the workbook carries only three Supervisor fields (name, Service CIDR, control-plane IP range), so collect the rest up front:

• 5 consecutive static IPs for the Supervisor control plane on the management network — 3 control-plane VMs + 1 floating IP + 1 reserved for rolling updates. The workbook’s “Control Plane IP Range” is this block.
• Supervisor API FQDN + DNS record — logging in by FQDN is required to avoid certificate issues; point the record at the floating IP (no load balancer) or the load-balancer VIP. Add it to the Step 1 DNS table.
• Service CIDR — private, unique per Supervisor (the default usually works; it must not overlap other Supervisors or the fleet networks).
• Load balancer — Supervisor activation requires one; pick per WLD (intake H5): the built-in NSX/VPC LB (no extra appliance), the Foundation Load Balancer (platform-packaged L4 active/passive pair, for VDS networking), or Avi — then the whole Avi section above applies and must be complete before activation.
• North-south connectivity — the hard prerequisite. The workload domain’s own NSX connectivity model (intake H4, chosen per WLD, independent of the management domain’s) must be built and up before activation, along with its Supervisor-specific reservations:
  • VCF Networking with VPC (Distributed connectivity): the Distributed Transit Gateway + VNA cluster, a routable external IP block (north-south NAT / load-balancer VIPs, advertised upstream via BGP) and a private transit gateway IP block — in 9.1 this block must be a /16 (9.0 accepted a /24; with a /24 in 9.1 the deployment never completes — see the references below).
  • NSX segment networking (Centralized connectivity): the Edge cluster + Tier-0 first, plus ingress and egress CIDRs for the Supervisor.
  • VDS networking: distributed port groups for the workload network(s) (one designated primary), on a different subnet than the Supervisor management network, plus the FLB or Avi from the LB bullet (a VDS-networking Supervisor has no built-in NSX load balancer).
• Cluster readiness — vSphere DRS (fully automated) and HA enabled on the target cluster(s); storage policies chosen for the control-plane VMs, ephemeral disks, and image cache.
• Kubernetes content — Supervisor services / VKS release binaries come from projects.packages.broadcom.com (already in the Public URLs table below); air-gapped sites must plan the offline content-library path.
• Routing — the Supervisor management network must reach vCenter and the ESX hosts’ management vmkernel (Spherelet), and the workload network must reach the load-balancer VIPs.
• Zones — vSphere Zones must be created in vCenter before activation (vCenter → vSphere Zones → Add New vSphere Zone), one cluster per zone: three zones for a multi-zone Supervisor, one compatible cluster for single-zone. The activation wizard selects zones, it does not create them, and the single- vs multi-zone choice cannot be reversed afterwards. All clusters in a zone must sit on the same vDS. A three-zone Supervisor also needs ≤ 100 ms latency between the zone clusters (see 03-multi-az-prep.md for the stretch/AZ groundwork, and 10-supervisor-enablement.md §1.3 for the procedure).

TechDocs: vSphere Supervisor Platform (per-networking-path requirements pages) and Requirements for Simplified Supervisor Deployment (routing + FQDN-login requirements). The 9.1 /16 transit-gateway change is lab-documented in VCF 9.1 Home Lab Series Part 9 — Deploy Supervisor and the VCF 9.1.x Ultimate Deployment Guide.

Active Directory

When needed: Bring-up. The domain must be reachable and the accounts and groups must exist before the deployment starts (deployment plan E4 story 4.3). Using them for fleet SSO is Day-N — see the next section.

• Supported OS: Windows Server 2019 or 2022.
• Parent domain (forest root) reachable from SDDC components.
• Bind / service accounts and admin groups pre-created before install: the AD bind accounts you plan for vSphere / NSX, the Identity Broker bind account (see below), and the admin groups you will map to VCF roles — capture them in the intake (section C, e.g. C5).
• Decide the bind account’s password-expiry policy, and write down every system that uses it. Creating the account is the easy part; what breaks later is its rotation. The same bind account typically backs vCenter’s identity source, NSX’s LDAP configuration, VCF Operations, Log Management and the Identity Broker — each caches the credential independently, so one password change breaks all of them at once and each fails silently until somebody tries to log in. Either exempt the account from expiry deliberately, or own a rotation runbook that walks a maintained list of consumers. Doing neither means the domain’s normal expiry schedule decides when your fleet loses authentication.
• AD DCs reachable from every management component.

When every AD login fails at once: recognise the signature before you start debugging. Field-verified 2026-07-22 — an expired/changed bind password took down all AD authentication to the Identity Broker, and the symptoms actively mislead:

• The service’s own health endpoint reports healthy. The broker’s /acs/health returned true throughout, and its OIDC discovery, signing keys and configuration were all fine — none of that touches the directory binding. A green health check does not mean people can log in.
• The error message is deliberately uninformative. “Authentication was unsuccessful. Verify your credentials or contact your administrator if the issue persists” is the same string for a wrong password, a user outside the search base, a failed service-account bind, and a missing role mapping — it is anti-enumeration, so read nothing into it.

The signature to recognise: all AD users failing simultaneously + the service reporting healthy = bind credential or LDAPS trust, essentially always. Two cheap confirmations, in order: does a local account still log in (if yes, it is the directory side), and does a direct bind with the configured credential succeed:

$e=New-Object System.DirectoryServices.DirectoryEntry("LDAP://<dc-fqdn>:636/DC=example,DC=com","<bindDN>","<password>"); $e.NativeObject; "bind OK"

If the bind fails it is the account or the LDAPS path; if it succeeds the problem is base DN / search filter / group-role mapping instead. Also check the LDAPS certificate expiry on the DCs — the other cause of every AD login dying at once, with the same misleading symptoms.

Workbook gotcha: the Active Directory Inputs tab that the workbook’s own prereq row points at is hidden in the 9.1 workbook (v1.9.1.001) and still carries VCF 4.x/5.x-era content — Workspace ONE Access and Aria Suite Lifecycle groups, old Aria product names, HCX/HRM service accounts, VMw@re1! reference passwords. Unhide it for the svc-* / gg-* naming convention only; the actual 9.1 account set is the short list above.

Identity source for the VCF Identity Broker

When needed: Day-N. The broker ships at bring-up but is configured Day-2 (deployment plan E8 story 8.5) — collect these inputs early so that day isn’t spent chasing AD.

VCF 9 federates fleet-wide SSO through the VCF Identity Broker. The broker itself is deployed at bring-up with the VCF Management Services (no opt-in; its FQDN + services-runtime IP are part of the Step 1 plan) — what happens Day-2 is its configuration (deployment plan E8, story 8.5 fleet SSO). Prepare the AD-over-LDAP identity source up front; it has specific inputs and well-known gotchas.

What to prepare:

• Bind / service account — a dedicated AD account with read access to the base DN. If you use the Global Catalog, it must also have read on the TGGAU (Token-Groups-Global-And-Universal) attribute.
• Base DN (e.g. dc=example,dc=com), a Base Group DN (required to sync groups), and optionally a Base User DN.
• LDAPS root CA certificate in PEM format (with the BEGIN CERTIFICATE / END CERTIFICATE lines) if you use an encrypted connection (recommended).
• Domain controllers — a primary (and a secondary for failover), or DNS auto-discovery via SRV records; reachable on 389/636 (see 07-firewall-ports.md).
• Groups to sync, including the group you will map to the admin role.

Common gotchas:

• Login is the domain UPN (user@domain.com), not the email address — even when the email is synced, users must sign in with the domain UPN (Broadcom KB 393150). Trips up organisations where the email suffix differs from the UPN suffix.
• Global Catalog syncs only universal groups — local/global groups won’t appear until converted to universal, and the bind account needs the TGGAU read permission.
• The LDAPS certificate must be PEM (with BEGIN/END CERTIFICATE lines) — a missing or wrong-format root CA breaks the encrypted connection.
• Single Base Group DN — to sync groups spread across OUs, set the base group DN high enough to cover them all; a too-narrow DN silently misses the admin group.
• Nested groups — enable Sync Nested Group if admin membership comes via nested groups, or those members won’t sync.
• Sync runs weekly by default — a service-account password expiry or lockout will quietly stop group updates.

Other supported identity sources: OpenLDAP, and external IdPs — Microsoft Entra ID (OIDC / SAML) and AD FS. Those need different prep; see Broadcom’s Configure an Identity Provider (per-IdP sub-pages) and Configure Active Directory as an Identity Provider Using AD/LDAP on TechDocs. These are deliberately the 9.0 pages — the 9.1 doc set does not republish the SSO setup section, so 9.0 is the newest published version.

Once this prep is done, the actual configuration — the identity-provider wizard, federating vCenter/NSX/VCF Operations/VCF Automation/Supervisor/Log Management, and role assignment per product — is 12-sso-configuration.md.

Host Overlay TEP addressing (static IP pool recommended)

When needed: Bring-up. The Installer asks for the pool (or expects DHCP) while deploying the management domain.

How each host gets its GENEVE tunnel-endpoint (TEP) IPs on the ESX Host Overlay VLAN. Either way, size for at least nodes × pNICs IPs plus growth — e.g. a 4-node cluster × 2 pNICs = 8 IPs minimum.

• Recommended: static IP pool — entered directly in the VCF Installer at bring-up (and per cluster in the workload-domain wizard). No external DHCP service to build, monitor, or keep alive; and in stretched (multi-AZ) designs no per-AZ DHCP scope per TEP subnet. The P&P workbook’s own Deploy Management Domain sample uses IP Pool for the IP Assignment (TEP) field.
• Alternative: DHCP scope on the ESX Host Overlay VLAN — fully supported, same sizing rule; use it when the network team already operates DHCP on that VLAN and prefers central address management.

Broadcom TechDocs accepts either for the prerequisite — “a static IP pool or a DHCP server configured and advertising IP addresses on the … NSX host overlay (Host TEP) VLAN” (Create a New Workload Domain). TEP IP pools can also be created per cluster after bring-up (Create an IP Pool for Tunnel Endpoint IP Addresses).

DNS

When needed: Bring-up. The single most common cause of a failed bring-up — A and PTR must both resolve before the Installer runs.

• Forward + reverse zones for every FQDN in the Deploy Management Domain, Deploy Workload Domain and Deploy Cluster sheets. All A and PTR records present before deploy.
• Every FQDN and IP unique — each FQDN must resolve to a unique, currently unassigned IP address (workbook + the FQDN inventory page below).
• Create every FQDN lowercase — TechDocs requires it for the fleet-services family (“Do not use capital letters in the FQDN”), and creating all records lowercase avoids the trap entirely — see the Step 1 plan (01-network-dns-plan.md §C).
• Dynamic updates: Nonsecure and secure.
• Replication scope: all DNS servers in the forest.
• Two DNS servers configured on every appliance.
• One CNAME wrapping the two NTP A-records for round-robin (see below).
• The authoritative per-component FQDN/IP inventory is in Broadcom TechDocs: VCF Components FQDNs and IP addresses (9.1 Planning and Preparation).

NTP

When needed: Bring-up. Hosts and appliances must be in sync before deployment — skew breaks certificate validation and cluster formation.

• Two external time sources per site (radio/GPS, upstream NTP, or NTP served by the ToR switches / physical routers).
• Two A-records pointing at the two sources.
• One CNAME (e.g. ntp.sfo.rainpole.io) → A-record name for round-robin HA.
• The two external servers themselves synced to different upstreams (healthy NTP dispersion).
• Optional: per-server A-records (e.g. ntp0 / ntp1) for direct management of the individual sources.
• AD domain controllers synced to the same external NTP.
• Different time sources for different fault domains / sites.

Source: the workbook’s Prerequisite Checklist → NTP block (incl. the A-record/CNAME construction). Host-side setup: TechDocs Configure NTP on the ESX Hosts.

SMTP

When needed: Day-N. Alerting is configured in VCF Operations after bring-up.

• Mail relay reachable from each SDDC component (alerting).
• Restrict relay to SDDC management IP range(s).
• The consumer is VCF Operations’ outbound Standard Email plug-in (alert notifications), configured Day-2 with exactly these values — TechDocs: Configure Email Alert Plug-in Settings.

Certificate Authority

When needed: Day-N. Bring-up runs on self-signed certificates; the CA-signed replacement is done once the fleet exists (deployment plan E6 6.2 partial / E8 8.5 full). Have the CA reachable and its template validated before bring-up anyway — the environment gate (E4 story 4.3) checks it, and a missing template blocks the entire Day-2 certificate pass.

• VCF 9.1 fleet certificate management (VCF Operations → Fleet Management → Certificates → Configure CA for Fleet) offers two CA types: Microsoft CA or OpenSSL. It’s a single fleet-level setting — there is no separate Microsoft-only restriction for “management” vs “instance” components.
• External / third-party CA is CSR-based only: VCF generates the CSR, you sign it on your CA, and import the signed certificate. The private key never leaves VCF — you cannot import a certificate that was created entirely outside VCF (VCF does not accept an externally-generated private key).
• Microsoft CA: must support Basic authentication; recommended Windows Server 2019/2022 with the Certificate Authority + Certificate Authority Web Enrollment roles (Web Enrollment on the same host as the CA role). The full four-step prep (roles, basic auth, certificate template, least-privilege service account) is TechDocs Prepare Your Microsoft Certificate Authority to Allow VMware Cloud Foundation to Manage Certificates.
• Have ready for the Configure-CA wizard (Microsoft CA): the CA server URL (https://<ca-fqdn>/certsrv), the least-privileged service account + password, and the issuing certificate template name.
• OpenSSL: configured on the appliance with the org details (Common Name, Country, Locality, Organization, OU, State) — no external prerequisites.
• The certificate pass is a bulk operation — but it must be staggered. Field-verified 2026-07-22 on a real deployment. In VCF Operations → Fleet Management → Certificates you tick multiple components in the list and act on them together: Generate CSRs, Download CSRs, Replace With Configured CA Certificate, Import Certificates (plus Renew Certificates and Replace With Imported Certificates). Progress is reported per batch as an n/total counter, and the UI notes changes may take some time to appear after the task reports success. Three planning consequences:
  • Generate before replace. The Replace With Configured CA Certificate dialog states “Last generated Certificate Signing Requests (CSRs) will be used for generating certificate(s)” — the replace consumes the most recently generated CSRs rather than issuing fresh ones. Regenerate if the component’s SANs/FQDN changed since the last generate, or you will sign a stale request.
  • Do not fire batches in parallel. The dialog carries a mandatory acknowledgement behind this caution: “Each certificate rotation can trigger automated retrust operations across dependent components. To avoid system instability, wait for any current or ongoing batch operations to be completed before starting the next.” So the change window budgets fewer, larger batches with a settling wait between them — not one sweeping fleet-wide action, and not many small ones fired concurrently.
  • The CA burst is real. A batch submits every selected CSR at once. On a Microsoft CA, confirm the issuing template does not require manual approval — an approval-gated template turns a bulk generate into a stalled queue rather than an error.
  • A failure does not stop the batch. Field-verified 2026-07-22: when one component’s replacement failed, the remaining ones kept progressing. A batch is therefore partial-success by design — it will not halt and wait for you. The n/total counter is the only signal that something did not land (5/6 means one failed), so read the final count and open the task list, rather than treating “the batch finished” as “the fleet is certified”. Re-run the failed components as their own small batch once the current one has settled, and verify per component at the end of the pass.
  • The CSR dialog ships with Broadcom’s placeholders — replace them. Field-observed 2026-07-22: Generate CSR pre-fills Organization Broadcom, Organizational Unit vcfms, Country United States of America, State CA, Locality Palo Alto, and defaults Key Size to 2048. Easy to click straight past — and then wrong in every certificate you issue. Agree the subject fields with whoever owns the CA (they may be enforced by the template anyway) and confirm 2048 meets the site’s crypto policy before generating in bulk.
  • DNS/FQDN SAN is a required field. Even for components deployed IP-only — VCF Operations for Networks is the example (see 05-day2-deployments.md §B.2) — so every component you intend to certify needs a resolvable name planned in Step 1. For a multi-node/clustered appliance the dialog requires “FQDNs and IPs of all nodes”.
  • NSX Manager: watch for a backup running concurrently. Field-observed 2026-07-22 — the one failure in a batch was an NSX Manager, with an NSX backup in progress at the time. The working theory (not confirmed) is that the rotation triggers a backup itself and does not wait long enough for it to finish before proceeding. Either way the mitigation is the same: check that no NSX backup is running or scheduled in the window, and give NSX Manager its own batch rather than bundling it with a long run of ESX hosts. If it fails, re-run it alone once the backup has completed.
• The certificate list also carries an Auto-renewal Status column. In a freshly deployed 9.1 fleet the entries observed were Deactivated — treat auto-renewal as something you opt into, and check expiry ownership rather than assuming the fleet renews itself.
• TechDocs walk-throughs: Configure a Certificate Authority for VMware Cloud Foundation and the umbrella Managing Certificates in VMware Cloud Foundation section.

SFTP backup target

When needed: Day-N. The fleet-wide backup target is configured in VCF Operations right after bring-up (deployment plan E6 story 6.3) — build it in parallel with the deployment, not after go-live.

• SFTP target (TCP 22) reachable from the VCF management network — SDDC Manager, NSX Manager, vCenter and the fleet components — VCF Automation plus the VCF management services (Log Management, Identity Broker, Software Depot, fleet/SDDC lifecycle, real-time metrics, Salt) — all back up to it.
• Service account + write path pre-created (e.g. svc-vcf-bck → /backups/).
• The external SFTP server must support 256-bit ECDSA and 2048-bit RSA SSH keys, with host key algorithms including one of rsa-sha2-512 / rsa-sha2-256 and one of ecdsa-sha2-nistp256 / nistp384 / nistp521.
• FIPS is on by default in 9.x SDDC Manager and cannot be turned off, so the FIPS-mode SSH requirements always apply: the server must also offer a KEX from diffie-hellman-group-exchange-sha256 / ecdh-sha2-nistp256 / nistp384 / nistp521, and the MAC hmac-sha2-256 (not only the -etm@openssh.com variant — a common hardening trap). Verify the handshake before registering the target: 08-backup-target.md §4.
• A backup encryption passphrase chosen and stored in a password manager with a named owner — it is required during restore; a lost passphrase makes every backup on the target useless.
• Placed outside the management domain it protects — a backup target that dies with the platform is not a backup.

Build guidance (what backs up and how often, placement, a hardened chrooted OpenSSH worked example, gotchas) + references: 08-backup-target.md. TechDocs: File-Based Backups for SDDC Manager, NSX Manager and vCenter and Configure SFTP Backup Target in VCF Operations. Note the workbook’s own SFTP row is stale here — it still says NSX + SDDC Manager “configured through SDDC Manager”; in 9.1 the fleet-wide target is set in VCF Operations and covers the components listed above.

Jump host

When needed: Bring-up. Nothing starts without it.

The machine the whole deployment is driven from. It must exist before day one and survive independently of the platform it deploys — don’t place it on the cluster being built (or on storage that depends on it).

• Routed access to: ESXi mgmt, VM mgmt, VCF mgmt, and the internet (binary downloads, if the online depot is used).
• Modern browser — VCF Installer UI, vCenter, NSX Manager, VCF Operations.
• OVF Tool — deploys the VCF Installer appliance OVA.
• SSH client — PuTTY, or the OpenSSH client built into Windows 10+ / Windows Server 2019+ (appliance console work on the VCF Installer, SDDC Manager, vCenter).
• SFTP/SCP client — WinSCP (or plain scp/sftp) for moving bundles, certificates, and log collections on and off appliances.
• PowerShell 7 + VCF PowerCLI — needed if you build a custom ESX ISO (vendor add-ons / async drivers), and generally useful for day-2 automation.
• Excel — for the P&P workbook itself.
• Verification tools — nslookup / Resolve-DnsName for the DNS gate and w32tm (Windows) / ntpdate -q (Linux) for the NTP gate, run from the same network vantage point the appliances will use.

Binaries

When needed: Bring-up. The depot decision (G1) drives infrastructure — an offline depot is a web server you have to build, so decide it early.

Everything else comes through the depot — decide online, offline, or manual transfer early (intake G1), because the offline path means building infrastructure:

• Online depot — VCF Installer and the fleet talk to the Broadcom depot directly; have the Download Service ID + Activation Code ready (intake G2/G3) and outbound 443 per the Public URLs table below. Generating the download credential requires the Product Administrator role on the Broadcom support-portal site — arrange it early (see 09-binary-depot.md). TechDocs: Connect VCF Installer to Broadcom or an Offline Depot and Download Binaries.
• Offline depot (air-gapped) — the VCF Download Tool is the only supported method in 9.1; you also need a web server (≥ 1 TB disk, HTTPS) to serve the downloaded depot store. TechDocs: Download Binaries to an Offline Depot by Using the VCF Download Tool.
• Manual transfer (one-off installs) — VCF Download Tool on any internet-connected machine, then copy + import the depot store on the VCF Installer appliance itself; no depot server, but Day-N patching needs repeat side-loads into the fleet Depot Service. TechDocs: Manually Transfer Binaries to VCF Installer.

Build guidance (depot web server setup, Download Tool commands, transfer + connect steps, using the tool standalone to pre-stage binaries) + references: 09-binary-depot.md.

Public URLs (online functionality)

When needed: Bring-up (if in scope). Only if something goes online — the platform, or (air-gapped) the machine running the VCF Download Tool.

Everything online in VCF 9.1 — depot downloads, licensing, compatibility / vSAN HCL data, CEIP — talks to a short list of public URLs, all outbound TCP 443. Hand this table to the firewall team as-is, and if egress goes through a proxy (intake G5), have these allowlisted on it. Source: Public URLs Required for Online Functionalities (earlier versions: KB 327186).

Proxying these? The proxy must be reachable from the whole services-runtime node block, not just the depot/Ops IPs. Allowlisting these URLs on the proxy is only half of it: the fleet also has to reach the proxy, and a fleet-side proxy precheck does a plain TCP (netcat) connect from a pod that can land on any VCF services-runtime node. Broadcom’s documented access doesn’t call this out, so the proxy port often gets opened only for the depot + VCF Operations IPs and the proxy config then fails to apply. Firewall the whole node block to the proxy port. Full writeup + how to read the precheck logs: 09-binary-depot.md §5.

Air-gapped? The platform itself then needs none of these — but the machine running the VCF Download Tool still does, from wherever it runs. Plan that host’s outbound access (or proxy allowlist) as part of this gate.

Two notes on the newer rows. The three CEIP endpoints (vcsa.vmware.com, vcsa.telemetry.broadcom.com, scapi.telemetry.broadcom.com) are distinct destinations, not alternatives — allowlist all three if telemetry is on. The api.prod.nsxti.vmware.com row applies only when vDefend IDS/IPS is in scope (it is not part of the base VCF SKU); a fleet without vDefend threat-prevention can drop it.

Sign-off

Confirm in writing that all items above are green before the intake meeting (Step 2) — the Bring-up ones because they stop the deployment, the Day-N ones because a gap found on the day you need them costs the same time, just later. If anything is amber/red, capture the owner, target date, and risk before starting the workbook.