EnglishFrançaisDeutschEspañolItaliano日本語한국어NederlandsPortuguês (Brasil)中文 (简体)中文 (繁體, 台灣)
Skip to main content

2026 年 9 月 15 日

フェーズ 3、オプション 1 - Access Wizard を使用した Omnissa Access の展開

このリリース以降、access-wizard は、ブートストラップ ノードのセットアップ、Control Plane の初期化、Control Plane の展開、Access およびインフラストラクチャ サービスの展開、テナント作成の手順を 1 つのガイド付きコマンドで自動的に実行します。このウィザードは、一連の短い質問を表示し、その回答を構成ファイルに書き込み、展開ステージを順番に実行します。これらの手順を個別に実行する場合は、「Omnissa Access の手動展開」を参照してください。

**注：**Access Wizard 26.07 は、Omnissa Access 26.07.0.0 のグリーンフィールド デプロイをサポートします。既存の環境を更新して新しいリリースを展開することは、このバージョンの範囲外です。

IP アドレス、証明書など、必要な情報を事前に用意していれば、アンケートへの回答は数分で終わります。以降の自動展開には 1.5 ~ 2 時間ほどかかります。

はじめに

開始する前に、次の内容を確認します。

注：

  • このウィザードはブートストラップ ノードのディスク容量と Docker ストレージを検証し、他のすべてのノードへの SSH 接続と認証を確認します。リモート ノードの CPU、RAM、またはディスクのサイジングは独立して検証されません。開始する前に、「フェーズ 1 - Omnissa Access インストールのための仮想マシンの準備 」のサイジングの表で確認してください。
  • Access Wizard の RPM がデジタル署名されている。署名の検証（以下の「 署名キーの信頼と RPM の確認」を参照）は、次のセクションの SHA-256 チェックサム検証とは別のチェックです。チェックサムは、ダウンロードが破損していないことを確認するもので、Omnissa からの正規のダウンロードであることを確認するものではありません。

Access Wizard のダウンロードと確認

手順：

  1. Omnissa Customer Connect にログインして、次のものをダウンロードします。

    • Omnissa Access アセット バンドル（Control Plane マニフェストとコンテナ イメージを含む ZIP ファイル）。
    • Access Wizard RPM バンドル - RPM (access-wizard-26.07.noarch.rpm)、.sha256 チェックサム ファイル、Omnissa RPM 署名パブリック キー (omnissa-linux-rpm-gpg-key.pub) の 3 つを含む ZIP ファイル。

  2. ローカル マシンで RPM バンドルを解凍します（またはブートストラップ ノードにコピーした後に解凍します。手順は次のセクションを参照してください）。

    unzip <wizard-bundle>.zip

  3. バンドルに含まれる .sha256 ファイルに対して RPM を確認し、公開されたチェックサムと照合してアセット バンドルを確認します。

    sha256sum -c access-wizard-26.07.noarch.rpm.sha256
sha256sum <asset-bundle>.zip

    いずれかの値が一致しない場合は続行しないでください。

ブートストラップ ノードへのファイルのアップロード

手順：

  1. 両方の zip をブートストラップ ノードにコピーします。

    scp <wizard-bundle>.zip <asset-bundle>.zip \
    configuser@<bootstrap-ip>:/home/configuser/

  2. ブートストラップ ノードに configuser として接続し、RPM バンドルを解凍します。

    ssh configuser@<bootstrap-ip>
unzip <wizard-bundle>.zip

    この手順の残りの部分では、configuser としてログインしたままにしておきます。以降のすべてのコマンドでは、明示的な sudo を使用します。

署名キーの信頼と RPM の確認

手順：

  1. Omnissa RPM 署名パブリック キーをインポートします（RPM バンドルを解凍したディレクトリから実行）。

    sudo rpm --import omnissa-linux-rpm-gpg-key.pub

  2. RPM 署名と整合性を確認します。

    sudo rpm -K access-wizard-26.07.noarch.rpm

    出力に、有効なダイジェストと署名が示されている必要があります。検証に失敗した場合は、RPM をインストールしないでください。

RPM のインストール

手順：

sudo dnf install -y access-wizard-26.07.noarch.rpm

インストールされるパッケージの ID は access-wizard-26.07-1.noarch です。

インストールの確認

手順：

sudo access-wizard --version

期待される出力：

access-wizard 26.07

ガイド付き展開の開始

手順：

sudo access-wizard deploy --asset-bundle /<path>/<asset-bundle>.zip

ウィザードには、6 つの質問セクション（基本情報、テナント、インフラストラクチャ ノード、Access ノード、証明書、オプション サービス）を含む「ようこそ画面」が表示され、Enter キーを押して開始するように指示されます。

   ●   OMNISSA ACCESS   —   Deployment Wizard

Official documentation
  • Release Notes
    - https://docs.omnissa.com/bundle/workspace-one-access-release-notesV26.07/page/workspace-one-access-release-notes.html
  • Install Omnissa Access
    - https://docs.omnissa.com/bundle/workspace-one-access-installation-guideV26.07/page/InstallingOmnissaAccess.html
  • Deploy Access & Infrastructure
    - https://docs.omnissa.com/bundle/workspace-one-access-installation-guideV26.07/page/DeploytheOmnissaAccessandInfrastructureServices.html

  View or copy all official documentation URLs: sudo access-wizard docs

-------------------------------------------------------------
 Omnissa Access - guided deployment
-------------------------------------------------------------
This wizard asks what it needs, writes your config files, and runs
the deployment in the right order. If a step doesn't validate, it
stops and tells you what to look at rather than pressing on.

There are 6 sections of questions.

The deployment itself takes about two hours. If your connection
drops during it, reconnect and run:

    sudo access-wizard resume

It continues from the last completed deployment stage without asking the
questionnaire again.

  1. Basic information
  2. Tenant
  3. Infrastructure nodes
  4. Access nodes
  5. Certificates
  6. Optional services

Press Enter to begin.

セクション 1：基本情報

  1. https://www.omnissa.com/general-terms/ で EULA を確認し、[承諾] をクリックします。

    =============================================================
Section 1 of 6: Basic information
=============================================================


-------------------------------------------------------------
License agreement
-------------------------------------------------------------

Before anything else, please read and accept the end user license agreement.

  Review it at https://www.omnissa.com/general-terms/

Do you agree to these terms? [Y/n]:
  EULA accepted <acceptance-timestamp>

  2. ウィザードで自動的に検出されたアセット バンドルを確認します。ウィザードは、公開されたチェックサムを使用して整合性を検証します。

    -------------------------------------------------------------
  Asset bundle verification
-------------------------------------------------------------

    ✓  Asset integrity                    <verification-detail>

  3. クラスタ名を選択します。これにより、/opt/wss/<cluster_name> 作業ディレクトリのパスが決まります。

    -------------------------------------------------------------
Cluster
-------------------------------------------------------------

Choose a short name for this deployment.

The wizard creates /opt/wss/<cluster_name>. This becomes the working
directory for future WSO administration and maintenance commands.

What would you like to call this cluster?: <cluster_name>

  Working directory will be /opt/wss/<cluster_name>
  Your answers are saved to /opt/wss/<cluster_name>/wizard.ini

  4. 展開サイズ（小規模、中規模、大規模）を選択します。ウィザードに、各オプションのノード トポロジが表示されます。

    What size deployment is this?

Every deployment uses 3 Infrastructure nodes. The number of Access
nodes and supported scale depend on the deployment size.

  1) Small    2 Access nodes   300,000 users     3,000 groups    50 apps
  2) Medium   2 Access nodes   1,000,000 users  10,000 groups   150 apps
  3) Large    3 Access nodes   1,000,000 users  20,000 groups   500 apps
Choose 1-3: 1

✓  Deployment size                    Small
    Topology:    3 Infrastructure + 2 Access nodes

  5. ブートストラップ ノードで検出された IP アドレスを確認します。

    -------------------------------------------------------------
  This node
-------------------------------------------------------------

  This looks like the Bootstrap node, with IP address <bootstrap-ip>.
  Is that right? [Y/n]: Y

  6. 共有の configuser パスワードを入力します。ウィザードがブートストラップ ノードですぐに検証を行います。このパスワードをリセットする必要がある場合は、「Omnissa Access Control Plane クラスタ ノードの管理」を参照してください。

    -------------------------------------------------------------
Credentials
-------------------------------------------------------------

The credentials the cluster uses to reach every node.

  This is the configuser password you already set when you deployed
  the OVA. Not a new one. It must be the same on every node.

Enter the configuser password:********
Enter it again to confirm:********

  Validating configuser authentication on Bootstrap (<bootstrap-ip>)...
  configuser password validated against Bootstrap.

  7. クラスタが他のノードで認証を行う方法（入力したパスワード、または生成された SSH キー ペア）を選択します。

    • パスワード

      How should the cluster authenticate to the Infrastructure and Access nodes?
  1) password   use the password you just entered
  2) ssh_key    generate a key and copy it to every node
Choose 1-2: 1

    • ssh_key

      How should the cluster authenticate to the Infrastructure and Access nodes?
  1) password   use the password you just entered
  2) ssh_key    generate a key and copy it to every node
Choose 1-2: 2

  8. 環境で該当する場合は、ロード バランサの IP アドレスと X-Forwarded-For IP アドレスを入力します。ウィザードがポート 443 の接続を確認します。

    -------------------------------------------------------------
Load balancer
-------------------------------------------------------------

The load balancer sits in front of your Access nodes.

  It should already be configured with X-Forwarded-For headers
  enabled. You'll add the Access nodes as upstreams once they're
  deployed.

What is the load balancer IP address: <load-balancer-ip>

  Checking...
    Load balancer  <load-balancer-ip>   port 443 reachable

-------------------------------------------------------------
X-Forwarded-For trusted proxies
-------------------------------------------------------------

The load balancer and Access node IPs are included automatically.
Enter only additional trusted proxy, WAF, CDN, or other forwarding-hop IPs.

Do you need to add any additional IPs for X-Forwarded-For? [y/N]: y
Additional trusted IP: <trusted-proxy-ip>
    Added  <trusted-proxy-ip>
Add another trusted IP? [y/N]: n
  Section 1 complete.

セクション 2：テナント

テナント プリフィックスとベース ドメインを入力します。ユーザーは https://<tenant-name>.<base-domain>で展開にアクセスします。ウィザードは、FQDN がロード バランサの IP アドレスに解決されることを確認し、テナント管理者のユーザー名（デフォルトは admin）、名、姓、メール アドレスの入力を求めます。

=============================================================
 Section 2 of 6: Tenant
=============================================================

Now configure the tenant your users will sign in to.

  Load Balancer URL: https://tenant.acme.example.com
  Tenant:            tenant
  Base domain:       acme.example.com

What should the tenant be called: <tenant-name>
What is the base domain: <base-domain>

  Users will reach this deployment at:

    https://<tenant-name>.<base-domain>

  Checking DNS...
    <tenant-name>.<base-domain> resolves to <load-balancer-ip>
    Matches the load balancer.

-------------------------------------------------------------
 Tenant administrator
-------------------------------------------------------------

The first administrator account for this tenant.

What should the administrator's username be? [admin]: admin
Administrator's first name: <first-name>
Administrator's last name: <last-name>
Administrator's email address: <administrator-email>

  Section 2 complete.

セクション 3：インフラストラクチャ ノード

各 3 つのインフラストラクチャ ノードの IP アドレスを入力します。ウィザードは SSH の到達可能性を確認し、入力時に各ノードに対して認証を行います。重複するアドレスは拒否されます。

=============================================================
 Section 3 of 6: Infrastructure nodes
=============================================================

Every deployment uses 3 Infrastructure/Platform nodes, regardless
of size.

These run the platform services (Vault, Consul, Nomad) and the
shared infrastructure: PostgreSQL, Redis, Kafka, and OpenSearch.

What is the IP address of Infrastructure node 1: <infra-ip-1>
What is the IP address of Infrastructure node 2: <infra-ip-2>
What is the IP address of Infrastructure node 3: <infra-ip-3>

  Checking SSH reachability and authentication on each Infrastructure node...

    ✓ Infrastructure node 1  <infra-ip-1>     reachable and authenticated
    ✓ Infrastructure node 2  <infra-ip-2>     reachable and authenticated
    ✓ Infrastructure node 3  <infra-ip-3>     reachable and authenticated

  All 3 Infrastructure nodes are reachable and authenticated.

  Section 3 complete.

セクション 4：ノードへのアクセス

各 Access ノードの IP アドレスを入力します（小規模または中規模の場合は 2、大規模の場合は 3）。ウィザードがそれぞれの到達可能性と認証を確認します。

=============================================================
 Section 4 of 6: Access nodes
=============================================================

Your small deployment uses 2 Omnissa Access nodes.

These run the Access application services and sit behind your load
balancer. Platform services also run here.

What is the IP address of Access node 1: <access-ip-1>
What is the IP address of Access node 2: <access-ip-2>

  Checking SSH reachability and authentication on each Access node...

    ✓ Access node 1  <access-ip-1>      reachable and authenticated
    ✓ Access node 2  <access-ip-2>      reachable and authenticated

  All 2 Access nodes are reachable and authenticated.

  Section 4 complete.

セクション 5：証明書

Access がテナントの FQDN に使用する TLS 証明書を選択します。

  • 自己署名 - 展開中に自動的に生成されます。
  • カスタム - 独自の PEM 証明書とプライベート キーをブートストラップ ノードにアップロードします。ウィザードは、証明書チェーン、キーの一致、テナントの FQDN カバレッジを検証します。

  • 自己署名

    =============================================================
Section 5 of 6: Certificates
=============================================================

Access needs a TLS certificate for <tenant-name>.<base-domain>.

What certificate should Access use?
  1) self-signed   generated for you during deployment
  2) custom        your own certificate from a CA
Choose 1-2: 1

  Section 5 complete.

  • カスタム

    =============================================================
Section 5 of 6: Certificates
=============================================================

Access needs a TLS certificate for <tenant-name>.<base-domain>.

What certificate should Access use?
  1) self-signed   generated for you during deployment
  2) custom        your own certificate from a CA
Choose 1-2: 2

-------------------------------------------------------------
What you need
-------------------------------------------------------------

Two files, both PEM format:

  Certificate    complete chain, with the server certificate first,
                followed by any intermediate CA certificates;
                the file starts with
                -----BEGIN CERTIFICATE-----

  Private key    text file starting with
                -----BEGIN PRIVATE KEY----- or
                -----BEGIN RSA PRIVATE KEY-----
                It must not be encrypted or password protected.

The certificate must cover <tenant-name>.<base-domain>, as the Common
Name or a Subject Alternative Name. A wildcard (*.<base-domain>)
also works.

Upload both to this node. From your workstation:

  scp mycert.pem mykey.pem configuser@<bootstrap-ip>:/home/configuser/omnissa-upload/

I've created /home/configuser/omnissa-upload for you.

Where are your certificate files?
  1) Already uploaded to this node
  2) Not yet, I'll upload now - wait for me
  3) Actually, use a self-signed certificate instead
Choose 1-3: 1

  Checking /home/configuser/omnissa-upload...

    <mycert>.pem      <size> KB    certificate
    <mykey>.pem       <size> KB    private key

  Found a certificate and key. Use these? [Y/n]: Y

  Checking the certificate...

    Format          PEM certificate
    Covers          <tenant-name>.<base-domain>  (via wildcard *.<base-domain>)
    Issued by       <Issuer>
    Valid until     <date>  (<> days from now)
    Key match       yes

  Certificate accepted.
  Both files will be copied into place when deployment starts.

  Section 5 complete.

セクション 6：オプションのサービス

SMTP、NTP、NFS 共有ストレージ、Android 版モバイル SSO の Cert-Proxy の 4 つのオプション。[y/N] プロンプトで n と応答し、その項目を延期します。この 4 つはすべて、access-wizard configure で展開が完了した後に再設定できます。

**注：**ブートストラップ ノードは、入力した NTP サーバの DNS 名解決を検証します。

=============================================================
 Section 6 of 6: Optional services
=============================================================
Four optional items. All can be configured later if you'd rather
get the deployment running first.

-------------------------------------------------------------
 Email (SMTP)
-------------------------------------------------------------

Access sends email for password resets, notifications, and new
user invitations. Without it, the administrator can still sign in
using the reset link created at the end of this deployment, but no
other user will receive email.

Configure SMTP now? [y/N]: n

-------------------------------------------------------------
 Time synchronization (NTP)
-------------------------------------------------------------

Cluster nodes need their clocks in sync. Certificate validation and
token expiry both depend on it, so drift causes authentication
failures that are hard to trace.

Do you have an NTP server? [y/N]: n

-------------------------------------------------------------
 Shared storage (NFS)
-------------------------------------------------------------

Optional shared storage for the cluster.

Do you have NFS storage to configure? [y/N]: n

-------------------------------------------------------------
 Cert-Proxy (Mobile SSO for Android)
-------------------------------------------------------------

Cert-Proxy enables Mobile SSO for Android devices.
It can be configured later if you skip it now.
Configure Cert-Proxy (Mobile SSO for Android)? [y/N]: y

Which certificate should Cert-Proxy use?
  1) Reuse the Load Balancer certificate selected above (recommended)
  2) Use a different certificate and private key
Choose 1-2: 1

Section 6 complete.

確認と決定

6 つのセクションをすべて完了すると、ウィザードに回答のサマリが表示されます。

=============================================================
 Ready to deploy
=============================================================

  CLUSTER
    Name                 <cluster_name>
    Working directory    /opt/wss/<cluster_name>
    Size                 small
    Bootstrap            <bootstrap-ip>
    Load balancer        <load-balancer-ip>
    Credentials          configuser (password set)
    Authentication       SSH key
                         password used for initial key distribution
    Asset bundle         <asset-bundle>.zip
    EULA                 <verification-detail>

  TENANT
    URL                  https://<tenant-name>.<base-domain>
    Username             <username>
    Administrator        <first-name> <last-name>
    Email                <administrator-email>

  INFRASTRUCTURE NODES
    Node 1               <infra-ip-1>
    Node 2               <infra-ip-2>
    Node 3               <infra-ip-3>

  ACCESS NODES
    Node 1               <access-ip-1>
    Node 2               <access-ip-2>

  X-FORWARDED-FOR TRUSTED HOPS
    Load balancer        <load-balancer-ip>
    Access nodes         <access-ip-1>, <access-ip-2>
    Additional trusted IPs <trusted-proxy-ip>
    Final trusted list   <load-balancer-ip>, <access-ip-1>, <access-ip-2>, <trusted-proxy-ip>

  CERTIFICATE
    Type                 custom
    Covers               <tenant-name>.<base-domain>  (via wildcard *.<base-domain>)
    Expires              <date>

  OPTIONAL
    Cert-Proxy           enabled (FQDN_CERT)
    SMTP                 not configured
    NTP                  not configured
    NFS                  not configured

-------------------------------------------------------------

  This takes roughly 1.5 to 2 hours:

    Loading images          5 minutes
    Control plane deploy    30-60 minutes
    Services deploy         40 minutes
    Tenant creation         5-10 minutes

  You don't need to stay at the terminal. Progress is shown here
  and written to /opt/wss/.omnissa-wizard/logs/

  At the end you'll get a password reset link for the
  administrator account. It expires in 24 hours, so be ready to
  copy it.

  Everything above has been saved to /opt/wss/<cluster_name>/wizard.ini
  If you stop now, nothing has been changed on any node.

-------------------------------------------------------------

  Is everything above correct?
    1) Yes, continue to validation
    2) No, let me change something
    3) Exit without deploying
  Choose 1-3:

検証に進むには [1]、変更するには [2]、デプロイせずに終了するには [ 3] を選択します。

Is everything above correct?
  1) Yes, continue to validation
  2) No, let me change something
  3) Exit without deploying
Choose 1-3: 1

ウィザードに、最終的な準備状況のサマリが表示され、展開を開始するように求められます。

-------------------------------------------------------------
 Deploying
-------------------------------------------------------------
  ✓  Workflow continuation              protected from SSH disconnects

-------------------------------------------------------------
 Stage 1 of 7 - Validate prerequisites
-------------------------------------------------------------

Checking this Bootstrap node before making deployment changes.

  ✓  Root privileges                    running as root
  ✓  Required commands                  all available
  ✓  Node authentication                6 nodes verified (password)
    ✓ Bootstrap           <bootstrap-ip>      AlmaLinux 9.6
    ✓ Infrastructure 1    <infra-ip-1>        AlmaLinux 9.6
    ✓ Infrastructure 2    <infra-ip-2>        AlmaLinux 9.6
    ✓ Infrastructure 3    <infra-ip-3>        AlmaLinux 9.6
    ✓ Access 1            <access-ip-1>       AlmaLinux 9.6
    ✓ Access 2            <access-ip-2>       AlmaLinux 9.6

  ✓  Node OS validation                 6 nodes running AlmaLinux 9.6
  ✓  Asset bundle located               access-26.07-assets.zip
  ✓  Asset bundle structure             manifest and Linux CLI found
  ✓  Working-directory disk space       132 GB available
  ✓  Docker storage                     44 GB available at /var/lib/docker
  ✓  Disconnect protection              systemd transient services
  ✓  Cluster node connectivity          5/5 answering on SSH
  ✓  Load balancer port 443             <load-balancer-ip> reachable
  ✓  Tenant certificate files           certificate and key available


  Pre-deployment readiness

    ✓ Bootstrap authenticated · <boostrap-ip>
    ✓ Infrastructure nodes 3/3 authenticated
    ✓ Access nodes 2/2 authenticated
    ✓ Node addresses unique and validated
    ✓ Configuration ready for deployment

    1) Start deployment
    2) Review or change configuration
    3) Re-enter the shared configuser password
    4) Exit safely

  Choose 1-4:

展開ステージ

ウィザードは、次の 7 つのステージを自動的に実行します。ターミナル セッションを開いたままにして、進行状況を監視してください。

ステージ名前処理
1前提条件の検証root 権限、必要なコマンド、ノード認証、OS 検証、アセット バンドルの整合性、ディスク容量、ロード バランサのチェック
2展開アセットの準備作業ディレクトリ、アセット バンドルのステージングと抽出、CLI のインストール、コンテナ イメージのロード
3クラスタの初期化クラスタ構成、SSH キーの配布（選択されている場合）、クラスタ インベントリ、Control Plane プロファイル
4クラスタの検証構成の事前チェック、インベントリの検証
5Control Plane の展開Vault、Consul、Nomad、プラットフォーム サービス。プラットフォームの健全性の検証
6Access サービスの展開Access プロファイル、構成同期、すべての Access アプリケーション サービス、サービス準備ゲート
7テナントの作成テナントの作成、reset-link ハンドオフ、SMTP 構成（選択されている場合）
-------------------------------------------------------------
 Stage 1 of 7 - Validate prerequisites
-------------------------------------------------------------
  ✓  Root privileges                    running as root
  ✓  Required commands                  all available
  ✓  Node authentication                6 nodes verified (password)
  ✓  Node OS validation                 6 nodes running <supported-os>
  ✓  Asset bundle located               <asset-bundle>.zip
  ✓  Asset bundle structure             manifest and Linux CLI found
  ✓  Working-directory disk space       <nn> GB available
  ✓  Docker storage                     <nn> GB available at <docker-root>
  ✓  Disconnect protection              systemd transient services
  ✓  Cluster node connectivity          5/5 answering on SSH
  ✓  Load balancer port 443             <load-balancer-ip> is listening
  ✓  Tenant certificate                 self-signed selected
OK  All prerequisites passed

-------------------------------------------------------------
 Stage 2 of 7 - Prepare deployment assets
-------------------------------------------------------------
  ✓  Working directory                  /opt/wss/<cluster_name>
  ✓  Asset bundle staged                ...
  ✓  Asset bundle extracted             ...
  ✓  WSO CLI installed                  /usr/bin/wso
  ✓  EULA acceptance                    recorded by the CLI
  ▓  Loading images  <elapsed>
  ✓  Container images                   loaded and verified

-------------------------------------------------------------
 Stage 3 of 7 - Initialize the cluster
-------------------------------------------------------------
  ✓  Cluster initialization             cp-cluster / <size>
  ✓  Cluster inventory                  5 nodes across 12 groups
  ✓  Control Plane profile              generated defaults retained

-------------------------------------------------------------
 Stage 4 of 7 - Validate the cluster
-------------------------------------------------------------
  •  Optional Control Plane precheck    skipped
  ✓  Cluster inventory                  validated

-------------------------------------------------------------
 Stage 5 of 7 - Deploy the Control Plane
-------------------------------------------------------------
  ▓  Control Plane deployment  <elapsed>
  ✓  Control Plane                      deployed
  ✓  Platform health                    Vault, Consul, and Nomad healthy

-------------------------------------------------------------
 Stage 6 of 7 - Deploy Access services
-------------------------------------------------------------
  ✓  Access profile                     written
  ✓  Access configuration               synced to Vault and Consul
  ✓  <service-1>                        deployed
  ✓  <service-2>                        deployed
  ...
  ✓  <service-47>                       deployed
  ✓  Access services                    47/47 · 100%
  ✓  Service readiness                  all services READY

-------------------------------------------------------------
 Stage 7 of 7 - Create the tenant
-------------------------------------------------------------
  ▓  Tenant creation  <elapsed>
  ✓  Tenant                             created successfully

接続が切断された場合、またはウィザードを中断した場合

resume コマンドは、最後に完了した展開ステージから続行されます。有効なまま完了した作業はスキップされます。以前に保存した質問の回答は再度要求されません。

  • **質問への回答中：**Ctrl + C キーを押してから resume を実行すると、保存済みの回答が復元されます。
  • **保護された展開ステージの監視中：**Ctrl + C キーを押すと、ターミナルが切断されます。展開は停止しません。SSH セッションが切断されても、保護されたステージは引き続き実行されます。

どちらの場合も、進行状況を確認するか続行するには、再接続して次のコマンドを実行します。

sudo access-wizard status
sudo access-wizard resume

テナントの作成と完了

ステージ 7 の終わり近くに、ワンタイム パスワード リセット リンクが画面に表示されます。**すぐにコピーする - 24 時間後に期限切れになります。ログ ファイルには書き込まれません。**保存後に CONTINUE と入力します。

=============================================================
 COPY THIS NOW - the link expires in 24 hours
=============================================================
  Login URL   https://<tenant-name>.<base-domain>
  Username    admin
  Reset your password at:
  <one-time-reset-link>

質問への回答で SMTP を設定した場合、Omnissa CLI は、この時点で SMTP サービス アカウントのパスワードの入力を求めます。

SMTP uses a secure password prompt from the Omnissa CLI.
Enter SMTP Password: ********
  ✓  SMTP                               configured

展開が完了すると、ウィザードには、展開の所要時間、テナント URL、管理者ユーザー名、クラスタ名、ノード数などの完了のサマリが表示されます。質問で任意の項目をスキップした場合、後で構成する内容の一覧が「未処理の項目」行に表示されます。

---------------------------------------------------------------
 Deployment complete
---------------------------------------------------------------
  ✔ All done - total time: <elapsed>
  Tenant URL     https://<tenant-name>.<base-domain>
  Administrator  admin
  Cluster        <cluster_name>
  Nodes          3 Infrastructure, 2 Access

  Still outstanding:
    SMTP is not configured. Run: sudo access-wizard configure

  PLATFORM ACCESS

    From /opt/wss/<cluster_name>/cp-cluster/cp-cluster.env

      Nomad      https://<nomad-ip>:4646
      Consul     https://<consul-ip>:8501
      Vault      https://<vault-ip>:8202

    Administrative tokens are stored in the protected environment file:
    /opt/wss/<cluster_name>/cp-cluster/cp-cluster.env (root-only, mode 600)

    To display tokens securely:
    sudo access-wizard show-tokens

  Logs from this run are in: /opt/wss/.omnissa-wizard/logs/

トラブルシューティングを行う場合は、show-tokens ではなく、ノードから同じ値を直接読み取ることができます。

sudo cat /opt/wss/<cluster_name>/cp-cluster/cp-cluster.env

展開後

ステータスを確認します。

sudo access-wizard status

---------------------------------------------------------------
 Progress
---------------------------------------------------------------
  Cluster      <cluster_name>
  Tenant       <tenant-name>.<base-domain>
  done       Prerequisite validation
  done       Working directory preparation
  done       Deployment asset preparation
  done       Workspace ONE configuration
  done       Cluster initialization
  skipped    SSH key configuration
  done       Cluster configuration
  done       Control Plane profile
  skipped    Control Plane precheck
  done       Cluster inventory validation
  done       Control Plane deployment
  done       Platform health validation
  done       Access profile preparation
  done       Access configuration synchronization
  done       Access services deployment
  done       Service readiness
  done       Tenant creation
  done       SMTP configuration
  All phases complete.

プラットフォーム トークンを表示します（Nomad、Consul、Vault は展開後に自動的に表示されません）。

sudo access-wizard show-tokens

インタラクティブ ターミナルが必要です。プロンプトが表示されたら、REVEAL と入力します。

SMTP、NTP、NFS、または Cert-Proxy を構成します。access-wizard configure コマンドは、展開が完了した後にのみ実行されます。このコマンドは、1 回のパスで 4 つの項目をすべて確認し、それぞれに [y/N] の選択を求めます。設定を変更しない場合は、n と応答します。

[root@ng-bootstrap wss]# access-wizard configure
  Full session log: /opt/wss/.omnissa-wizard/logs/session-20260807-220226-configure.log

-------------------------------------------------------------
 Optional configuration
-------------------------------------------------------------
Configure the optional settings you need. Answer no to leave a
setting unchanged and continue to the next one.

Configure SMTP? [y/N]: n

Configure NTP? [y/N]: n

Configure NFS? [y/N]: n

Configure Cert-Proxy (Mobile SSO for Android)? [y/N]: n


-------------------------------------------------------------
 Configuration complete
-------------------------------------------------------------
  SMTP         unchanged
  NTP          unchanged
  NFS          unchanged
  Cert-Proxy   unchanged

Omnissa から診断の送信を求められた場合は、サポート バンドルを収集します。

sudo access-wizard support-bundle

これにより、ログ、構成、環境の詳細を含む編集されたアーカイブが /opt/wss/.omnissa-wizard/に書き込まれます。送信する前に内容を確認してください。

その他のコマンド：access-wizard には、credentials、verify-control-plane、docs、deploy --dry-run オプションも用意されています。使用方法の詳細を確認するには、access-wizard --helpを実行します。

展開中にサービスが失敗した場合

ステージ 6（Access サービスの展開）で、サービスが正常な状態でないことが報告された場合は、展開全体を再開するのではなく、リカバリを実行します。

  1. 停止しているステージまたはサービスを確認します。

    sudo access-wizard status

  2. ステータスの内容に基づいて続行方法を決めます。

    • Control Plane の展開が「running」の場合は、再開を試みないでください。代わりに Omnissa サポートでサポート チケットを開き、サポート バンドルを送信します。

      sudo access-wizard support-bundle

    • Control Plane の展開が「done」で、特定の項目が「失敗」になっていない場合は、次のコマンドで再開します。

      sudo WIZ_CP_REDEPLOY=yes access-wizard resume

      これは、健全性の検証、アクセス プロファイル、アクセス サービスの順に取得します。

    • Control Plane の展開が「done」で、ステータスの出力で特定の Access サービスの失敗が報告されている場合（X/47 として報告されます）は、まずそのサービスの問題を解決します。

      1. Nomad ユーザー インターフェイスを開き、失敗したジョブを見つけてパージします（再起動でなく、停止して削除します）。

      2. ブートストラップ ノードのクラスタ作業ディレクトリから 1 つのサービスのみを再度展開します。

        cd /opt/wss/<cluster_name>
wso services deploy -s <service-name>

        **注：**自動フロー中に失敗したサービスのみを展開します。

      3. そのサービスが正常に展開されたら、ウィザードを再開します。

        sudo access-wizard resume

      次の順序で展開されたサービスのリスト：

      control-plane-logging
host-logging
telegraf-statsd
telegraf-asset-server
ingress
ingress-gateway-route-reloader
control-plane-backup
client-side-load-balancer
telegraf-uptime
cp-ops-dispatch
cp-ops-output-processor
kafka
kafka-monitoring
postgres
postgres-monitoring
pgbouncer
postgres-backup
postgres-diff-backup
postgres-operations
postgres-operations-vacuum
redis
redis-monitoring
opensearch
coredns
eecache
nginx-http
acs
crypto
cds
token
analytics
saas
federation
authcontrol
greenbox
ws1notifications
ws1ntfmanager
skycap
cas
certproxy
commchannel
launcher
ws1admin
hubconsole
mpsso
nginx-stream
usergroup

これは、最初の展開中だけでなく、サービスが不良な状態になった場合にも適用されます。同じリカバリ フローは、展開の完了後またはアップグレード中にも機能します。

このページは役に立ちましたか?

このトピックについてフィードバックを送信

このトピックは役に立ちましたか?

個人情報や機密情報は入力しないでください。

リンクを生成しています…