VMware ESXi online course

Install vCenter Single Sign-On Using Custom Install

Learn how to install legacy vCenter Single Sign-On separately with Custom Install, choose an SSO deployment mode, configure sites and ports, and verify the installation.

vCenter Single Sign-On (SSO) is the authentication service used by vSphere services. It provides a centralized identity and login mechanism for vCenter-related components, so administrators can authenticate against the SSO domain rather than configuring independent credentials for every service.

This lesson covers the legacy Windows-based vCenter Installer workflow in which SSO can be installed separately from vCenter Server, vCenter Inventory Service, and the vSphere Web Client. Exact screens, prerequisites, and available deployment modes depend on the applicable vCenter release.

What vCenter Single Sign-On Provides

vCenter SSO is the authentication component used by vSphere services. It validates users and issues the authentication information that allows authorized users to access vCenter-related services.

An SSO installation creates an internal SSO domain. The domain is commonly named vsphere.local, although the value should be selected deliberately during planning. The installation also creates an SSO administrator account, commonly written as administrator@vsphere.local. This account administers the SSO domain and is distinct from a Windows or Active Directory administrator account.

SSO may be installed together with vCenter Server and related services, or it may be deployed as a separate component. Separate deployment is useful when service placement, replication, site design, or operational separation matters.

Installation Approaches

Simple Install

Simple Install is an all-in-one option. It places SSO, vCenter Server, the vSphere Web Client, and vCenter Inventory Service on one host. This approach reduces the number of installation decisions and is often suitable for a small lab or a simple environment where all services can share a server.

Custom Install

Custom Install permits SSO to be installed independently of vCenter Server, Inventory Service, and the vSphere Web Client. Each component can then be placed and installed according to the architecture.

Installation option | Components installed | Host placement | Typical environment size | Primary use case | Key limitations or considerations

Simple Install | SSO, vCenter Server, vSphere Web Client, and Inventory Service | One host | Small or straightforward environments | Fast all-in-one deployment | Less separation and fewer placement options

Custom Install | Selected components, including SSO independently | One or more hosts | Medium, large, distributed, or multisite environments | Controlled component placement and topology design | Requires more planning, coordination, and validation

Choose Custom Install when SSO must run on a dedicated management host, when vCenter components are distributed across servers, when multiple sites must be represented, or when the design requires additional fault tolerance and service separation. It is also the appropriate starting point when later vCenter components must connect to a deliberately designed SSO environment.

Alternative: vCenter Server Appliance

The vCenter Server Appliance is a preconfigured Linux-based virtual appliance alternative to installing legacy vCenter components individually on Windows hosts. The appliance includes vCenter Server and associated services, including SSO.

Choosing the appliance changes the deployment workflow. Instead of following the Windows component installer sequence described here, the administrator deploys and configures the appliance. Evaluate the appliance or Windows-based installation during architecture planning, considering the applicable vCenter release, operating system requirements, service placement, lifecycle procedures, and integration needs.

Pre-Installation Planning and Prerequisites

Check the requirements for the exact vCenter release before launching setup. Do not assume that requirements from another release apply.

Validation item | Why it matters | How to verify | Failure impact

Operating system and software | The installer and services require supported platform components | Compare the host with the release compatibility and installation documentation | Setup may block or services may fail after installation

CPU, memory, and disk | SSO services need sufficient resources and installation space | Review host capacity and the selected installation directory | Prerequisite failure, poor performance, or incomplete installation

Database and authentication dependencies | Some topologies or related components require supported database and identity dependencies | Confirm supported versions and access before setup | Component installation or service connection can fail

DNS | Services depend on consistent host naming | Test forward and reverse lookups for the target and dependent hosts | Authentication and service registration errors

Static addressing and reachability | SSO endpoints must remain stable and accessible | Confirm static addressing and test connectivity between hosts | Dependent components cannot connect reliably

Time synchronization | Authentication and service communication are sensitive to clock differences | Verify a consistent time source on SSO, vCenter, and identity systems | Token validation and login failures

Administrative permissions | Installation modifies files, services, and configuration | Confirm local administrative rights and required service permissions | Setup cannot create or configure services

Firewall and ports | Dependent services must reach the SSO endpoint | Check local and network firewall rules and port availability | Connection timeouts or blocked registration

Credentials | The SSO administrator controls the SSO domain | Define password standards and secure credential storage | Loss of access or delayed recovery

Choose the application installation directory before setup. Ensure sufficient capacity for the application, logs, temporary files, and expected growth. Record the planned SSO hostname, domain, site, port, and installation path in the deployment plan.

Launching the Custom Install Workflow

  1. Log on to the target host with the administrative permissions required by the applicable release.
  2. Start the VMware vCenter Installer.
  3. Select the vCenter Single Sign-On installation component.
  4. Proceed through the introductory setup page.
  5. Read and accept the license agreement.
  6. Allow the installer prerequisite check to run.
  7. Resolve every relevant failure before continuing. Do not bypass prerequisite failures in a production deployment.

The prerequisite check may identify an unsupported operating system or missing software, insufficient memory or disk, inadequate permissions, DNS problems, or unmet network, database, and service dependencies.

Choose an SSO Deployment Mode

The deployment-mode page determines how this SSO instance relates to the SSO environment. The exact labels vary by legacy release, but the decision generally distinguishes a first SSO server from an additional server that connects to an existing environment.

Deployment mode | When to select it | Relationship to existing SSO environment | Site considerations | High-availability or multisite implications

Initial SSO server | This is the first server for a new SSO domain and topology | Creates the new internal SSO environment | Assign it to the planned primary site | Establishes the domain, site model, and replication foundation

Additional or connected SSO server | An existing SSO environment is being extended | Joins or connects to the existing domain according to the release workflow | Select the intended existing or new logical site | Requires working connectivity, compatible topology, and planned replication

Multisite or high-availability design | The environment spans locations or requires redundant SSO infrastructure | Uses the mode intended to extend the established SSO environment | Define site membership before adding nodes | Validate latency, replication, failure behavior, and recovery procedures

Select the initial-server option only when no existing SSO domain or topology is being extended. Selecting it for an additional server can create the wrong domain or an unintended independent environment.

For a multisite design, determine which SSO servers belong to each logical site and how replication will operate. A site represents a logical location grouping for SSO servers across one or more physical locations. Site selection affects replication relationships, service discovery, fault-tolerance planning, and the later installation of vCenter services.

Configure SSO Identity

Set a strong password for the SSO administrator account. In the common vsphere.local example, the account is administrator@vsphere.local. The account name combines the administrator identity with the internal SSO domain.

The SSO administrator is a privileged identity for administering the SSO domain. Store the credential in an approved secure password manager and document the recovery procedure appropriate to the deployed vCenter release. Losing this credential can prevent administration of the SSO domain and complicate recovery.

Do not confuse the internal SSO domain with an Active Directory domain. Identity sources can be configured separately after SSO deployment, while the SSO administrator remains an internal SSO identity.

Configure the SSO Site

Enter a meaningful site name that reflects the organizational or geographic design, such as a primary datacenter or management location. Site names should be standardized before additional SSO nodes are installed or replication is configured.

Good site names make topology diagrams, service placement, troubleshooting, and recovery procedures easier to understand. Avoid temporary names that may become ambiguous when a second datacenter or availability location is added.

Configure the SSO Network Port

Configure the SSO service TCP port during installation. For applicable historical vCenter versions, the default value is 7444.

Use the default when it is available and permitted by policy. Select a nondefault port only when the default conflicts with another service or an organizational policy requires a different value. Verify that the selected port is unused, allowed by local and intervening firewalls, and reachable from every dependent vCenter component.

Record the final hostname and port as an SSO endpoint. If the port changes, dependent component configuration and firewall rules must use the changed value.

Installation Inputs and Planning Values

Installer field | Example value | Purpose | Planning guidance

SSO administrator password | A unique strong password | Protects administration of the SSO domain | Use approved password standards and secure storage

SSO domain | vsphere.local | Defines the internal identity domain | Keep the value consistent across the intended SSO environment

Site name | Primary-Datacenter | Identifies the logical SSO location | Choose a stable name before adding nodes or replication

SSO service TCP port | 7444 | Provides the network endpoint for applicable versions | Confirm availability, reachability, and firewall access

Installation directory | A planned local application path | Determines where SSO files and services are installed | Select a supported path with adequate capacity

Review and Execute the Installation

  1. Choose the application installation directory.
  2. Review the installer summary carefully.
  3. Confirm the deployment mode and whether it creates or extends an SSO environment.
  4. Confirm the SSO domain, administrator identity, and password plan.
  5. Confirm the site name and TCP port.
  6. Confirm the destination path and available disk capacity.
  7. Start the installation only after validating all settings.
  8. Monitor completion status and retain installation logs for verification and troubleshooting.

Pay particular attention to the deployment mode. Correcting an incorrect topology after dependent services have been installed is more disruptive than correcting a value before setup begins.

Post-Installation Verification

Check | Expected result | Corrective direction if unsuccessful

SSO-related services | Required services are installed and running | Review service status, startup errors, and installation logs

Listening port | The configured SSO TCP port is listening | Check the configured port, local process ownership, and firewall rules

Administrator authentication | The SSO administrator can authenticate with the expected account format | Verify the domain, password, account format, and applicable recovery process

Domain and site | Values match the deployment design | Compare the installed configuration with the architecture plan

Network connectivity | Dependent hosts can resolve and reach the SSO endpoint | Test DNS, routing, firewall access, and time synchronization

Complete these checks before installing or connecting vCenter Server, Inventory Service, and the vSphere Web Client. Dependent components need the correct SSO hostname, domain, credentials, site relationships where applicable, and port.

Follow-On Configuration

SSO policy configuration is a separate administrative task. Review authentication policies after deployment, including password behavior and other controls supported by the applicable release. Policies should reflect organizational security requirements without preventing documented recovery operations.

For a separately deployed environment, install and configure the remaining vCenter components in the sequence required by the release documentation. Point each component to the documented SSO endpoint and verify registration before proceeding to the next component.

Maintain a deployment record containing the SSO hostname, TCP port, internal domain, administrator account format, site name, site relationships, replication design, installation directory, credentials location, and verification results.

Practical Examples

First SSO Deployment for a Distributed Environment

An organization places SSO on a dedicated management server. The administrator selects Custom Install and chooses the initial-server mode because no SSO domain exists yet. The administrator uses vsphere.local, creates a strong SSO administrator password, names the primary site for the main datacenter, confirms the port, and installs SSO. vCenter Server and the remaining components are installed afterward and directed to this SSO service.

Multisite SSO Planning

A company operates management infrastructure in two datacenters. The first SSO server is assigned to the primary site. Additional SSO infrastructure uses the installer mode intended to connect to the existing SSO environment. Site names, DNS, time synchronization, network reachability, and replication relationships are standardized before dependent vCenter services are added.

Port Conflict

The default SSO port is reserved by another service. The administrator selects an approved unused port, confirms that the service binds to it, updates firewall rules, and records the new endpoint for later component installations.

Simple versus Custom Install

A small lab chooses Simple Install because all services can share one host. A larger production environment chooses Custom Install so SSO can be placed separately and the service topology can support distribution, multisite planning, or higher availability.

Troubleshooting

The Prerequisite Check Blocks Installation

Likely causes include an unsupported operating system or missing software, insufficient disk or memory, inadequate permissions, or unmet network, DNS, database, or service dependencies. Read the specific failure, correct the environmental requirement, and run the validation again.

The Selected SSO Port Cannot Be Used

Another process may be listening on the default or selected port, or a local firewall or endpoint security product may block it. Identify the conflict, free the port or select an approved alternative, then update firewall rules and document the final endpoint.

Dependent Components Cannot Connect to SSO

Verify that SSO services are running and that the configured port is listening. From the dependent host, test name resolution and network connectivity. Confirm the SSO hostname, port, domain, and administrator credentials, and check intervening firewalls and time synchronization.

SSO Administrator Authentication Fails

Check the expected account format, password, and internal SSO domain. A common example is administrator@vsphere.local. If the password is unavailable, use the documented credential recovery procedure for the deployed vCenter version. After access is restored, review authentication and password policies.

An Additional Server Uses the Wrong Topology Mode

This usually occurs when the initial-server option was selected even though the server should have joined an existing SSO environment. Stop before installing dependent components, validate the intended topology, and use the mode that connects to the established environment. Document site membership and replication relationships.

Exam-Relevant Notes

  • Simple Install places SSO, vCenter Server, vSphere Web Client, and Inventory Service on one host.
  • Custom Install allows SSO and other vCenter components to be installed separately.
  • The first SSO server establishes the new SSO domain and topology; an additional server extends or connects to an existing environment.
  • vsphere.local is a common internal SSO domain example, not an Active Directory domain.
  • administrator@vsphere.local is the common format for the internal SSO administrator account.
  • TCP port 7444 is the historical default for applicable vCenter releases; always verify the release-specific behavior.
  • Site names, replication, DNS, time synchronization, and firewall reachability must be planned before adding SSO nodes or dependent services.

For related guidance, see vCenter SSO Installation.