VMware ESXi and vSphere Cluster Management
Install vCenter Single Sign-On Using Custom Install
Learn how to install legacy vCenter Single Sign-On separately with Custom Install, configure the first node, domain, site, port, and validate the deployment.
vCenter Single Sign-On (SSO) is the authentication and identity service used by vCenter-related components. It provides a common internal identity domain so services such as vCenter Server and the vSphere Web Client can authenticate users and communicate consistently.
This lesson covers the legacy Windows-based vCenter Installer workflow for installing SSO separately. Exact screens, supported operating systems, service names, ports, and topology options vary by vCenter release, so verify every value against the documentation for the exact version being deployed.
What vCenter Single Sign-On Provides
SSO centralizes authentication for vSphere management services. Instead of each component maintaining an unrelated user database, components can use the SSO domain and its authentication service.
- SSO domain: The internal identity domain created for vSphere authentication. A commonly seen example is
vsphere.local, but the domain must be selected according to the product version and organization’s naming plan. - SSO administrator: The privileged account for the internal SSO domain. Its usual format is
administrator@<SSO-domain>, such asadministrator@vsphere.local. - vCenter Server: The central management service for ESXi hosts, virtual machines, and vSphere inventory.
- vSphere Web Client: The web-based management interface used by older vSphere releases.
- vCenter Inventory Service: A legacy component that supports inventory-related data operations.
The SSO administrator account is not automatically the same as a Windows local administrator, an Active Directory administrator, or an ESXi root account. Protect its password and document the recovery process for the deployed release.
Choose an Installation Architecture
| Installation option | Components placed together or separately | Typical environment size | Topology flexibility | Typical use case |
|---|---|---|---|---|
| Simple Install | SSO, vCenter Server, vSphere Web Client, and Inventory Service are placed together on one host. | Small or straightforward environments | Low; services are coupled on one system. | An all-in-one deployment without separate-service, multisite, or SSO redundancy requirements. |
| Custom Install | SSO can be installed independently, followed by the other vCenter components on the same or different systems. | Medium or large environments | Higher; services and SSO topology can be planned separately. | Separated services, multisite planning, or high-availability designs. |
Simple Install is appropriate when a small environment does not need separate servers or a complex SSO topology. See Install vCenter Server Simple Install for that alternative approach.
Choose Custom Install when SSO must be deployed independently from vCenter Server and the other legacy components. This approach is especially important when planning multisite or high-availability SSO designs. A multisite deployment spans more than one logical site; high availability uses redundant components and planned failover behavior to reduce interruption. A site label alone does not provide replication, routing, failover, or service redundancy.
The vCenter Server Appliance (VCSA) is another deployment model: a preconfigured virtual appliance that runs vCenter Server and associated services. Its deployment workflow is different from the Windows Custom Install procedure described here. Do not mix appliance deployment steps with this installer workflow.
Plan the Deployment Before Running the Installer
Topology decisions become difficult to change after dependent vCenter services have been installed. Decide whether this server will be the initial node, meaning the first SSO server in a new deployment, or an additional node that joins or expands an existing SSO topology.
| Check | Why it matters | How to validate | Action if unsuccessful |
|---|---|---|---|
| Supported operating system and version compatibility | SSO and vCenter releases support specific operating systems, patch levels, and component combinations. | Check the compatibility requirements for the exact release. | Use a supported operating system or release combination before installation. |
| DNS forward and reverse resolution | Authentication services and certificates depend on stable host identity. | Resolve the planned fully qualified name in both directions using the operating system’s DNS tools. | Correct DNS records, hostname configuration, or resolver settings. |
| Time synchronization | Authentication tokens and certificates can fail when clocks differ significantly. | Compare the server clock with the approved time source and other management hosts. | Configure reliable time synchronization before proceeding. |
| Administrative privileges | The installer must create services, write protected directories, and modify system configuration. | Confirm local-administrator or required service-account access. | Run with the privileges required by the release and organizational policy. |
| Network connectivity | SSO must be reachable by future vCenter components and management clients. | Test routing, firewall policy, and host-to-host connectivity. | Correct routes, firewall rules, or security controls. |
| Required TCP port availability | The SSO service needs an unused listening port and reachable firewall path. | Check local listeners and security-product reservations. | Free the port or select an approved alternative and document it. |
| Disk capacity | Installation files, services, logs, and future maintenance require available space. | Check the destination volume and organizational capacity standard. | Free space or select a suitable local directory. |
| Topology decision | The first-node, additional-node, and existing-deployment choices determine how SSO is formed. | Record the intended sites, nodes, domain, and relationships. | Stop and resolve design ambiguity before installing. |
Also plan the server name, IP addressing, SSO domain, site name, administrator-password handling, recovery documentation, database requirements, and any version-specific topology prerequisites. Confirm that required network ports are reachable between this server and the hosts that will later run vCenter Server, Inventory Service, and the vSphere Web Client.
SSO Installation Inputs
| Installer setting | Purpose | Example value | Planning considerations |
|---|---|---|---|
| Deployment mode | Defines whether this is a new initial node or an expansion of an existing deployment. | Initial or first node | Choose according to the topology plan; do not guess. |
| SSO domain | Creates the internal identity namespace. | vsphere.local | Use a documented domain supported by the release and avoid confusing it with an external directory domain. |
| SSO administrator password | Protects the privileged internal SSO administrator account. | Stored securely, never embedded in documentation | Meet the release-specific password policy and record recovery information securely. |
| Site name | Identifies the logical SSO location. | DC-East | Use a consistent naming convention across locations. |
| SSO TCP port | Defines the service endpoint used by dependent components. | 7444 in the installer generation covered here | Port 7444 is a historical default and is version-specific. Check for conflicts and firewall restrictions. |
| Installation directory | Stores SSO program files and related data. | A local management volume | Follow capacity, backup, security, and organizational standards. |
Launch the Custom Install Workflow
- Log on to the prepared target server with the required local-administrator or approved installation account.
- Open the VMware vCenter Installer for the exact vCenter release.
- Choose the vCenter Single Sign-On component rather than the all-in-one Simple Install option.
- Read the welcome screen and continue.
- Accept the license agreement when the terms have been reviewed.
- Allow the installer to run its prerequisite validation checks.
Warnings that affect compatibility, DNS, connectivity, system resources, topology, or security should be resolved rather than ignored. A warning that appears harmless can become a later authentication, certificate, or component-connection failure.
Select the SSO Deployment Mode
| Situation | Appropriate deployment choice | Reason | Caution |
|---|---|---|---|
| First SSO installation in a new environment | Initial or first-node option | Creates the first SSO server and internal identity domain. | Record the domain, site, administrator format, and endpoint. |
| Adding an SSO server to an established topology | Additional-node or existing-deployment option | Connects the new node to the existing SSO design according to the release. | Use only when the existing node, site, and replication requirements are known. |
| Planned multisite deployment | The release-specific initial or additional-node choice that matches the site design | Associates SSO servers with the intended logical locations. | A site name does not replace DNS, routing, replication, or failover planning. |
| Planned high-availability design | A supported initial/additional-node arrangement documented for the release | Creates the intended redundant service topology. | Confirm that the selected version supports the desired design before installing. |
Select the initial-node option when this is the first SSO installation in the environment. Select an additional-node or existing-deployment option only when an SSO deployment already exists and the new server is intentionally being added to it. If the wrong mode is selected, stop before installing dependent components and follow the supported remediation or redeployment process for that release. Do not manually edit SSO topology data.
For a deeper explanation of the choices, read Deployment Modes in vCenter SSO.
Configure the Identity and Site Settings
- Enter and confirm the password for the SSO administrator account.
- Confirm or enter the internal SSO domain. Keep the domain name consistent with the topology plan.
- Set the site name, such as
DC-EastorDC-West, using the organization’s naming standard.
The administrator identity normally uses the form administrator@<SSO-domain>. It is a privileged internal identity, so do not expose its password in screenshots, tickets, shell history, or general runbooks.
In a multisite design, site names distinguish logical locations. They should be short, unambiguous, and consistently formatted. A site name is not a DNS name and does not itself establish communication or high availability.
Configure the SSO Service Endpoint
Select the TCP listening port presented by the installer. For the installer generation covered by this lesson, TCP port 7444 is the historical default. Applicability is version-specific; use the value shown and supported by the exact release.
Use a nondefault port only when the default is unavailable or conflicts with an approved security standard. Before proceeding, check whether another application, an incomplete previous installation, or a local security product is using or reserving the port.
Changing the port affects firewall rules, future vCenter component installation, certificates, service URLs, monitoring, and operational documentation. Every dependent component must use the same SSO host and selected port. Record the complete endpoint, for example https://sso01.example.invalid:7444, using the real approved hostname in your environment; do not substitute an IP address unless the release explicitly supports that design.
Choose the Installation Location and Review
- Select a local installation directory on a volume with adequate capacity.
- Apply organizational standards for backup, access control, logging, and service-data placement.
- Review the summary page carefully.
- Confirm the deployment mode, SSO domain, administrator identity format, site name, TCP port, and destination path.
- Start the installation and wait for it to finish without interrupting the installer.
- Save installer-generated logs and record the final settings for later component installation.
Validate the Installation
- Confirm that the installer reports successful completion.
- Use the operating system’s service-management tools to verify that the expected SSO services are installed and running. Service names and layouts vary by release.
- Resolve the SSO host name from the server and from the future vCenter component hosts.
- Test TCP reachability to the selected SSO port from the systems that will connect to it.
- Where the release provides an authentication or administration interface, verify that the SSO administrator credentials work.
- Confirm synchronized time between SSO and dependent systems.
- Prepare the SSO host name, domain, administrator account format, site, and port for installation of vCenter Server, Inventory Service, and the vSphere Web Client.
Do not provide one universal command sequence for service and port validation: supported commands, service names, paths, and port layouts differ between vCenter releases and operating systems. Use the operating system’s service manager, DNS lookup utilities, and appropriate TCP port-testing tools.
Troubleshoot Common Problems
Prerequisite validation fails
Likely causes include an unsupported operating system or patch level, insufficient privileges, a missing dependency, insufficient disk space, or inadequate system resources. Read the failed prerequisite carefully, compare the host with the exact release requirements, correct the condition, and restart the installer only after validation succeeds.
The selected SSO port is unavailable
Another application may be listening on the port, a previous incomplete installation may have left a service running, or a security product may reserve or block it. Identify the listener, decide whether it can be stopped or moved, and use an approved unused port only when all firewall and dependent-component settings can be changed consistently. Document any deviation from the default.
A later vCenter component cannot connect to SSO
Verify the recorded SSO host name, domain, administrator account, password, and port. Test DNS and TCP connectivity from the dependent host, check for firewall filtering, confirm time synchronization, and investigate certificate or endpoint mismatches after any hostname or port change. Review installer and service logs for the precise failure.
The wrong deployment mode was selected
This usually results from skipping topology planning, treating an additional node as an initial node, or choosing a standalone design despite a multisite requirement. Stop before installing dependent components and follow the product-supported remediation or redeployment path for the exact version. Do not attempt unsupported manual topology edits.
The SSO administrator account cannot be used
Check the account format and internal domain, such as administrator@vsphere.local. An incorrect password, password-policy failure, account lockout, or use of the wrong domain can prevent login. Review the applicable password and lockout policy and use the release-specific supported recovery process if the credentials are lost.
Next Configuration Tasks
- Configure SSO policies for password complexity, expiration, lockout, token lifetime, and authentication behavior as supported by the deployed release. See Configure vCenter SSO Policies.
- Add and test external identity sources, such as the directory services supported by the release.
- Assign groups and users to appropriate vCenter roles and permissions. See Assign Permissions.
- Install the remaining separately deployed components in the order required by the release: normally vCenter Server and then the applicable Inventory Service and vSphere Web Client components, supplying the recorded SSO endpoint.
- Install or connect the vCenter Server to the SSO service, then validate authentication and service communication before adding ESXi hosts to inventory. See Add ESXi Host to vCenter Server Inventory.
Exam-Relevant Notes
- Simple Install places the major legacy vCenter components together on one host; Custom Install allows separate component placement.
- The first SSO server uses the initial-node deployment choice. Additional-node choices belong to an already established topology.
- The SSO administrator is an identity in the internal SSO domain, not automatically a Windows or ESXi administrator.
- Site names identify logical locations in multisite designs; they do not provide DNS, replication, routing, or failover by themselves.
- TCP port 7444 is a historical default for the installer generation covered here, not a universal value for every vCenter release.
- Changing the SSO endpoint requires consistent updates to firewall rules, certificates, URLs, dependent installations, and documentation.