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.

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).

• IP allocation + DNS (A/PTR) — per-appliance FQDN / IP (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 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

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

Same shape as Management Domain. Minimum 3 hosts, 4+ recommended for prod.

TechDocs: Preparing ESX Hosts for VCF or vSphere Foundation covers the ESX install + basic host configuration this gate expects (all pNICs ≥ 10 Gbps; vSAN hosts certified on the compatibility guide).

Network

Avi Load Balancer (only if in scope)

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), a VCF Automation HA cluster VIP (an external LB also works), or tenant/workload load balancing. Deployed Day-2 from VCF Operations into the management domain — vCenter and NSX must already be configured. Prepare up front:

• 4 IPs + FQDNs on the VM Management network: 3 controller nodes + the cluster VIP. The VIP FQDN must be registered in DNS and resolve to the cluster VIP (A + PTR for all four, like every other appliance).
• 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 (break-glass) accounts.
• Firewall: admin access to the controller UI/API (443) and the Service Engine ↔ controller secure channel — see 07-firewall-ports.md §E.

Not the same thing as the external load balancer for VCF Operations (see the Network table above and 05-day2-deployments.md B.1) — that one is never served by VCF. TechDocs: Deploy Avi Load Balancer from VCF Operations. The P&P workbook has no Avi input fields — only sizing rows — so capture these values in the Step 1 plan / intake instead.

Active Directory

• Supported OS: Windows Server 2019 or 2022.
• Parent domain (forest root) reachable from SDDC components.
• Users + groups from the workbook’s Active Directory Inputs tab pre-created.
• AD DCs reachable from every management component.

Identity source for the VCF Identity Broker

VCF 9 federates fleet-wide SSO through the VCF Identity Broker (deployed and configured Day-2 — see the deployment plan E8). 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.

Host Overlay TEP addressing (static IP pool recommended)

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

• Forward + reverse zones for every FQDN in: Mgmt Domain, WLD, and Clusters tabs. All A and PTR records present before deploy.
• 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

• Two external time sources per site (radio/GPS or upstream NTP).
• Two A-records pointing at the two sources.
• One CNAME (e.g. ntp.sfo.rainpole.io) → A-record name for round-robin HA.
• AD domain controllers synced to the same external NTP.
• Different time sources for different fault domains / sites.

SMTP

• Mail relay reachable from each SDDC component (alerting).
• Restrict relay to SDDC management IP range(s).

Certificate Authority

• 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).
• OpenSSL: configured on the appliance with the org details (Common Name, Country, Locality, Organization, OU, State) — no external prerequisites.
• TechDocs walk-throughs: Configure a Certificate Authority for VMware Cloud Foundation and the umbrella Managing Certificates in VMware Cloud Foundation section (verify CA-type behaviour in-product — the docs lag the 9.1 UI).

SFTP backup target

• SFTP target (TCP 22) reachable from the VCF management network — SDDC Manager, NSX Manager, vCenter and the fleet components (VCF Automation, VCF Identity Broker) 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.
• 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-and-depot.md §A. TechDocs: File-Based Backups for SDDC Manager, NSX Manager and vCenter and Configure SFTP Backup Target in VCF Operations.

Jump host

• VM or physical with routed access to: ESXi mgmt, VM mgmt, VCF mgmt, internet (for binary downloads if online depot is used).
• Browser + ovftool installed.

Binaries

Everything else comes through the depot — decide online vs offline 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 08-backup-and-depot.md §B). 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.

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

Public URLs (online functionality)

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).

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.

Sign-off

Confirm in writing that all items above are green before the intake meeting (Step 2). If anything is amber/red, capture the owner, target date, and risk before starting the workbook.