A variety of external services are required for the initial deployment of Cloud Foundation and for the deployment of other optional components like vRealize Operations or vRealize Automation.

The following table lists the required and optional external services and dependencies.

Table 1. External Services
Service Purpose
Active Directory (AD) (Optional) Provides authentication and authorization.
Note: AD is required if you are deploying vRealize Automation.
Dynamic Host Configuration Protocol (DHCP) Provides automated IP address allocation for VXLAN Tunnel Endpoints (VTEPs) and NSX-T host VTEPs.
Domain Name Services (DNS) Provides name resolution for the various components in the solution.
Network Time Protocol (NTP) Synchronizes time between the various components.
Simple Message Transfer Protocol (SMTP) (Optional) Provides method for email alerts.
Certificate Authority (CA) (Optional) Allows replacement of the initial self-signed certificates used by Cloud Foundation.
Note: A CA is required if you are deploying vRealize Automation.

Active Directory

Cloud Foundation uses Active Directory (AD) for authentication and authorization to resources.

The Active Directory services must be reachable by the components connected to the management and vRealize networks.

User and Group accounts must be configured in AD prior to adding them to the SDDC Manager and assigning privileges.

If you plan to deploy vRealize Automation, Active Directory services must be available. See the vRealize Automation documentation (https://docs.vmware.com/en/vRealize-Automation/index.html) for more information about its AD configuration.


Cloud Foundation uses Dynamic Host Configuration Protocol (DHCP) to automatically configure each VMkernel port of an ESXi host used as a VTEP with an IPv4 address. One DHCP scope must be defined and made available for this purpose. The defined scope must be large enough to accommodate all of the initial and future servers used in the Cloud Foundation solution. Each host requires two IP addresses, one for each VTEP configured.

If you plan on creating an NSX-T workload domain, you need DHCP to configure TEP on the hosts.


During deployment, you will need to provide the DNS domain information to be used to configure the various components. The root DNS domain information is required and, optionally, you can also specify subdomain information.

DNS resolution must be available for all of the components contained within the Cloud Foundation solution. This includes servers, virtual machines, and any virtual IPs used. See Host Names and IP Addresses for details on the components requiring DNS resolution prior to starting a Cloud Foundation deployment.

Ensure that both forward and reverse DNS resolution is functional for each component prior to deploying Cloud Foundation or creating any workload domains.


All components must be synchronized against a common time by using the Network Time Protocol (NTP) on all nodes. Important components of Cloud Foundation, such as vCenter Single Sign-On (SSO), are sensitive to a time drift between distributed components. Synchronized time between the various components also assists troubleshooting efforts.

Requirements for the NTP sources include the following:
  • The IP addresses of two NTP sources can be provided during the initial deployment
  • The NTP sources must be reachable by all the components in the Cloud Foundation solution
  • Time skew is less than 5 minutes between NTP sources

SMTP Mail Relay (Optional)

Certain components of the SDDC, such as vCenter, Log Insight, and vRealize Automation, can send status messages to users by email. To enable this functionality, a mail relay that does not require user authentication must be available through SMTP. As a best practice, limit the relay function to the networks allocated for use by Cloud Foundation.

Certificate Authority (Optional)

The components of the SDDC require SSL certificates for secure operation. During deployment, self-signed certificates are used for each of the deployed components. These certificates can be replaced with certificates signed by an internal enterprise CA or by a third-party commercial CA.

If you plan to replace the self-signed certificates, the CA must be able to sign a Certificate Signing Request (CSR) and return the signed certificate. All endpoints within the enterprise must also trust the root CA of the CA.

If you plan to deploy vRealize Automation, a Certificate Authority is required, and the installation workflow will request certificates.