Separate the setup responsibilities
Initial setup crosses two trust boundaries:
- The host administrator runs Docker, protects the installation account, retrieves the setup token locally, and manages installation recovery material.
- The OneView setup administrator uses the protected browser workflow to connect PostgreSQL, create the first local administrator, activate the license, and complete setup.
One person may hold both responsibilities in a small deployment, but the client should still record which action uses host authority and which uses application authority.
Prepare before opening setup
Have these approved values and owners ready:
- the production hostname, TLS mode, DNS route, and firewall changes;
- a dedicated externally managed PostgreSQL database, user, preferred verified TLS configuration, and backup owner;
- the customer license key and its unused one-time activation code;
- an individual first-administrator identity;
- a restricted client recovery location for installation configuration, identity, and encryption material; and
- named owners for Docker, database, certificate, vendor, and OneView administration.
Review requirements, choose the appropriate installation mode, and confirm that the host can reach PostgreSQL, the OneView licensing service, and required vendor endpoints.
Complete setup safely
- Run the public installer as the dedicated operating-system account. Enter license and activation values only at its protected prompt; do not append them to shell history.
- Retrieve the setup token on the host and enter it only on the OneView setup page. The browser exchanges it for a short-lived HTTP-only setup session and clears it from the form.
- Connect PostgreSQL, review the returned safe connection facts, and save only after the selected TLS trust level and ownership are correct.
- Create the first administrator as an individual identity, not a shared account.
- Activate the license with the matching one-time code.
- When OneView verifies the host-provisioned encryption material, confirm the client's recovery responsibility. The browser verifies availability and permissions but never receives or displays the key.
- Complete setup, sign in through the production HTTPS address, replace any temporary password, and create a second named recovery administrator.
Setup tokens, activation codes, encryption keys, database passwords, and certificate private keys must not be copied into tickets, chat, screenshots, documentation, browser storage, or source control.
Verify the completed installation
- Run the sanitized installation report and retain it according to the client's support-data policy.
- Run network health checks from the configured application and verify browser reachability from an intended user device.
- Review active sessions and confirm only the expected setup browser is present.
- Create separate API Service Accounts only for applications that need supported public integration API access.
- Test the coordinated backup and recovery procedure before production verification data is stored.
Do not rerun bootstrap installation over a configured deployment. Use the documented diagnostics, network handoff, or controlled update runbook for later operational changes, and test the disaster-recovery runbook before relying on the installation in production.