Omnissa Access Connector のアップグレードの実行

Windows ベースの Omnissa Access Connector をバージョン 24.12 にアップグレードするには、新しいインストーラを Customer Connect からコネクタ サーバにダウンロードして、インストーラを実行します。古いバージョンのコネクタをアンインストールする必要はありません。

アップグレード中、既存のディレクトリ同期サービス、ユーザー認証サービス、Kerberos 認証サービスおよび仮想アプリケーション サービスは一時停止します。アップグレードの完了後、サービスは自動的に再起動されます。

**注：**このドキュメントでは、グラフィカル ユーザー インターフェイスを使用してコネクタをアップグレードする方法について説明します。サイレント インストールを使用してコネクタをアップグレードするには、「サイレント モードでの Omnissa Access Connector インストーラの実行」を参照してください。

重要な考慮事項

• FIPS モード

  FIPS モードが有効になっているバージョン 22.05 または 22.09 インストールからアップグレードする場合、アップグレードされたコネクタは FIPS モードで実行されます。FIPS モードが有効になっていないバージョン 22.05 または 22.09 インストール、または 22.05 より前のバージョンからアップグレードする場合、アップグレードされたコネクタは非 FIPS モードで実行されます。アップグレード中またはアップグレード後に FIPS モードを選択または選択解除することはできません。FIPS モード設定を変更するには、新規インストールを実行する必要があります。詳細については、『Omnissa Access Connector のアップグレード』を参照してください。

• es-config.json ファイル

  es-config.json 構成ファイルは、Omnissa Access サービスとコネクタ間の接続を確立します。ほとんどの場合、アップグレードされたコネクタは、既存のコネクタで使用されているのと同じ構成ファイルを使用できます。ただし、場合によっては、Omnissa Access コンソールから新しい es-config.json ファイルを生成する必要があります。

  • バージョン 20.01.x または 20.10.x からアップグレードする場合、アップグレード中またはアップグレード後に仮想アプリケーション サービスをインストールするには、新しい es-config.json 構成ファイルを生成して使用する必要があります。仮想アプリケーション サービスをインストールしない場合は、新しい構成ファイルは必要ありません。アップグレードされたコネクタは、既存のコネクタで使用されているのと同じ構成ファイルを使用できます。

  • バージョン 21.08.x または 22.05 からアップグレードしていて、Omnissa Access 21.08 リリース、または 2021 年 9 月のクラウド リリース以降に es-config.json 構成ファイルを生成した場合、新しい es-config.json ファイルを生成する必要はありません。

  • アップグレード元のバージョンに関係なく、既存の es-config.json 構成ファイルのパスワードが現在のパスワード ルールを満たさない場合、ルールを満たすパスワードを使用して新しい構成ファイルを生成する必要があります。

    パスワードは 14 文字以上で、1 つ以上の数字、1 つ以上の大文字、1 つ以上の特殊文字を含める必要があります。次の特殊文字のみを使用できます。

    @ ! , # $ { } ( ) _ + . < > ? *

    すべての文字は、表示および印字可能な ASCII 文字である必要があります。

  • 既存の構成ファイルのパスワードを忘れた場合は、新しい構成ファイルを生成し、アップグレード中に使用します。

  新しいファイルを生成するには、Omnissa Access コンソールで [統合] > [コネクタ] の順に移動し、[新規] をクリックして、ウィザードの [構成ファイルをダウンロード] ページで新しいファイルを作成します。

  注意：構成ファイルには、テナント URL、テナント ID、各エンタープライズ サービスのクライアント ID とクライアント シークレット、パスワード ハッシュなどの機密情報が含まれています。ファイルを共有したり、公開したりしないようにすることが重要です。

• RSA SecurID（クラウド デプロイ）認証方法の構成は、21.08 リリース以降、変更されました。RSA SecurID （クラウド デプロイ）認証方法を構成した 20.10.x 以前の Connector からアップグレードする場合は、すべてのユーザー認証サービス インスタンスをアップグレードする前に、アクセス ポリシーから認証方法を削除して、アップグレード後に再構成得る必要があります。これにより、RSA SecurID ベースのログインのダウンタイムが発生するため、ダウンタイムを考慮してアップグレードのタイミングを計画します。

  アップグレードを実行する手順の概要は次のとおりです。

  1. RSA Authentication Manager アプライアンス 8.2 SP1 以降（Omnissa Access Connector 21.08 以降でサポートされているバージョン）を使用していることを確認します。
  2. コネクタをアップグレードする前に、使用されているアクセス ポリシーから RSA SecurID（クラウド デプロイ）認証方法を削除します。
  3. ユーザー認証サービスがインストールされているすべてのコネクタをバージョン 24.12 にアップグレードします。
  4. プロキシ サーバにコネクタが構成されている場合は、RSA Authentication Manager サーバ用に構成された通信ポートがプロキシ サーバで開いていることを確認します。
  5. 複数の RSA Authentication Manager サーバ インスタンスを展開している場合は、ロード バランサの背後で構成し、ロード バランサの Omnissa Access 要件を満たす必要があります。
  6. RSA セキュリティ コンソールで、コネクタが完全修飾ドメイン名 (FQDN) を使用して認証エージェントとして追加されていることを確認します。たとえば、connectorserver.example.com です。
  7. RSA SecurID（クラウド デプロイ）認証方法の構成を更新します。
  8. アクセス ポリシーに RSA SecurID（クラウド デプロイ）認証方法を追加します。

• ユーザー認証サービスがインストールされているすべてのコネクタ インスタンスをバージョン 24.12 にアップグレードします。Omnissa Access は、ユーザー認証サービスのバージョンの混在をサポートしていません。

• Omnissa Access Connector 24.12 は、次のタイプのプロキシをサポートしています。

  • 非認証 HTTP プロキシ
  • 非認証 HTTPS (SSL) プロキシ
  • 認証済み HTTPS (SSL) プロキシ

前提条件

• 「Omnissa Access Connector のアップグレード」を確認してください。

• コネクタのインストールが仮想 Windows Server 上にある場合は、アップグレードする前に仮想マシンのスナップショットを作成します。

• プロキシ サーバ、Syslog サーバ、証明書など、既存のインストールのカスタム設定を書き留めます。これらの設定を構成し、アップグレード中に証明書を再度アップロードする必要があります。カスタム設定の完全なリストについては、「Omnissa Access Connector のインストール」を参照してください。

• Kerberos 認証サービスまたは仮想アプリケーション サービスをインストールする場合は、コネクタ サーバをドメインに参加させます。

• RSA SecurID（クラウド デプロイ）認証方法を構成している場合は、RSA Authentication Manager アプライアンス バージョン 8.2 SP1 以降を使用していることを確認します。

• RSA SecurID （クラウド デプロイ）認証方法を構成した 20.10.x 以前の Connector からアップグレードする場合は、ユーザー認証サービスがインストールされているすべてのコネクタ インスタンスをアップグレードする前に、アクセス ポリシーから認証方法を削除します。

  1. Omnissa Access コンソールで、[リソース] > [ポリシー] の順に移動します。

  2. 各ポリシーを確認し、RSA SecurID（クラウド デプロイ）認証方法がポリシーの一部である場合は削除します。

     コネクタのアップグレード後に認証方法を再度追加するために必要な情報として、変更の内容をメモしておきます。

• バージョン 20.01.x からアップグレードし、統合 Windows 認証 (IWA) 経由の Active Directory タイプのディレクトリを構成済みの場合は、アップグレードする前に、Omnissa Access コンソールのディレクトリ構成で [STARTTLS] オプションを選択解除します。アップグレード後、IWA 経由の Active Directory の機能は STARTTLS オプションとの互換性がなくなります。

  ディレクトリ構成を編集するには、[統合] > [ディレクトリ] ページに移動し、ディレクトリを選択して、[このディレクトリには STARTTLS を使用するすべての接続が必要] チェック ボックスを選択解除し、[保存] をクリックします。

• Omnissa Access コンソールで、すべてのコネクタ サービスを一時停止します。

  1. [統合] > [コネクタ] の順に選択します。
  2. コネクタを選択し、[管理] をクリックします。
  3. 各サービス名の横にある切り替えボタンをクリックして、サービスを一時停止します。

• 次のアカウント情報があることを確認します。

  • Omnissa Customer Connect 認証情報
  • 既存のインストールに Kerberos 認証サービスまたは仮想アプリケーション サービスが含まれている場合は、サービスの実行に使用されているドメイン ユーザー認証情報が必要です。
  • アップグレード中に Kerberos 認証サービスまたは仮想アプリケーション サービスをインストールする場合は、これらのサービスを実行するためのドメイン ユーザー アカウントが必要です。これらのサービスはドメイン ユーザー アカウント権限で実行されますが、ディレクトリ同期サービスとユーザー認証サービスはより低い権限で実行されます。
  • RSA SecurID（クラウド デプロイ）認証方法を使用する場合、すべてのコネクタ インスタンスをアップグレードした後に Omnissa Access コンソールで認証方法を再構成するために必要な情報を取得するには、RSA セキュリティ コンソールの資格情報が必要です。

手順

1. 必要に応じて、新しい構成ファイルを Omnissa Access コンソールで生成します。

   1. システム ドメインの管理者として Omnissa Access コンソールにログインします。

      **ヒント：**クラウド展開の場合、システム ドメイン管理者は、Omnissa Access テナントの取得時に認証情報を受け取る管理者です。オンプレミス展開の場合、システム ドメイン管理者は Omnissa Access インスタンスのインストール時に作成される管理者ユーザーです。

   2. [統合] > [コネクタ] の順に選択します。

   3. [新規] をクリックします。

   4. [新しいコネクタを追加] ウィザードで、[次へ] をクリックします。

   5. [構成ファイルをダウンロード] ページで、パスワードを作成して [構成ファイルをダウンロード] をクリックし、構成ファイルを生成します。

      パスワードは 14 文字以上で、1 つ以上の数字、1 つ以上の大文字、1 つ以上の特殊文字を含める必要があります。次の特殊文字のみを使用できます。

      @ ! , # $ { } ( ) _ + . < > ? *

      すべての文字は、表示および印字可能な ASCII 文字である必要があります。

      構成ファイルは、インストールするエンタープライズ サービスと Omnissa Access テナントとの間の通信を確立するために使用されます。このファイルは、デフォルトで es-config.json という名前になっています。

      注意：構成ファイルには、テナント URL、テナント ID、各エンタープライズ サービスのクライアント ID とクライアント シークレット、パスワード ハッシュなどの機密情報が含まれています。ファイルを共有したり、公開したりしないようにすることが重要です。

   6. インストーラ ファイルを、以前のバージョンのコネクタがインストールされている Windows Server に転送します。

2. Omnissa Customer Connect から Omnissa Access Connector 24.12 をダウンロードします。

   1. Customer Connect にログインします。

   2. [Omnissa Access Connector のダウンロード] ページに移動します。

   3. Access-Connector-Installer-versionNumber.exe をダウンロードします。

3. インストーラ ファイルを、以前のバージョンのコネクタがインストールされている Windows Server に保存します。

4. Access-Connector-Installer-versionNumber.exe ファイルをダブルクリックして、インストーラを実行します。

   インストーラによってアップグレードが必要であることが検出され、アップグレード プロセスの手順が表示されます。

5. ウィザードの指示に従ってコネクタをアップグレードします。

   • アップグレード中に [構成の指定] ページが表示される場合は、新規または既存の構成ファイルを選択し、そのパスワードを指定します。ファイルのデフォルトの名前は、es-config.json です。

   • [デフォルトまたはカスタム インストールの選択] ページで、コネクタのインストール時に選択したオプションを選択します。プロキシ サーバや Syslog サーバなどのカスタム設定を構成した場合、または証明書をアップロードした場合は、[カスタム] オプションを選択して設定を構成し、証明書を再度アップロードする必要があります。カスタム設定の完全なリストについては、「Omnissa Access Connector のインストール」を参照してください。
     注意：カスタム設定が構成されていて、アップグレード中に [デフォルト] を選択した場合、カスタム設定はデフォルト値にリセットされます。この場合は、インストーラを再度実行し、[カスタム] オプションを選択してカスタム設定を構成し、証明書を再度アップロードします。

   • アップグレード中に [信頼されるルート証明書のインストール] ページが表示され、信頼されるルート証明書をトラストストアにアップロードできます。コネクタは、証明書チェーンにトラストストアにアップロードされた証明書のいずれかが含まれているサーバおよびクライアントへの安全な接続を確立できます。信頼されるルート証明書が必要なシナリオは次のとおりです。

     • （オンプレミスのインストールのみ）自己署名証明書がオンプレミスの Omnissa Access サービス インスタンスにある場合は、エンタープライズ サービスと Omnissa Access サービス インスタンス間の信頼を確立するためにルート証明書および中間証明書（必要な場合）をアップロードする必要があります。
     • （Kerberos 認証サービスのみ）ロード バランサの背後に Kerberos 認証サービスの複数のインスタンスを展開する場合は、コネクタ インスタンスにロード バランサのルート CA 証明書をインストールして、コネクタとロード バランサ間の信頼を確立する必要があります。
     • （仮想アプリケーション サービスのみ）仮想アプリケーションのコレクションを作成して、Omnissa Horizon®、シングル ポッド ブローカを使用した Omnissa Horizon® Cloud Service on Microsoft Azure、または Horizon Cloud Service on IBM Cloud に統合し、Horizon Server に自己署名証明書がある場合は、仮想アプリケーション サービスがインストールされているコネクタ インスタンスに証明書チェーンをアップロードして、コネクタと Horizon Server 間の信頼を確立する必要があります。Horizon Server にパブリック認証局によって署名された証明書がある場合は、コネクタ トラストストアに証明書をアップロードする必要はありません。パブリック認証局によって署名された証明書を使用することを強くお勧めします。

     注意：証明書パスに、一部の言語で使用される 2 バイト文字が含まれていないことを確認してください。パスに 2 バイト文字が含まれている場合、アップグレードは成功する可能性がありますが、証明書は正しくアップロードされません。

     アップグレード中に証明書をアップロードする場合は、アップグレードの完了後にサービスを再起動してください。

     証明書のアップロードは、アップグレードのオプション手順です。インストーラを再度実行して、アップグレード後に証明書をアップロードすることもできます。

     

   • アップグレード中に、インストーラは OpenJDK 17 をインストールします。

   • アップグレード中に、既存のサービスの設定を変更できます。他のサービスをインストールすることもできます。たとえば、既存のインストールにディレクトリ同期サービスのみが含まれていて、ユーザー認証サービスと Kerberos 認証サービスをインストールする場合は、アップグレード中にインストールできます。

     要件、サイズ設定、インストール、および設定の詳細については、『Omnissa Access Connector のインストール』のバージョン 24.12 を参照してください。

   • （仮想アプリケーション サービスのみ）カスタム インストール フローを使用すると、アップグレード中に新しい [Citrix 構成] ページが表示されます。このページのオプションは、マルチサイトの集約またはキーワード フィルタリングが構成されている Citrix 環境との Omnissa Access 統合に適用されます。

     

     詳細については、『Omnissa Access でのリソースのセットアップ』の「Omnissa Access での Citrix マルチサイトの集約およびキーワード フィルタリングの構成」、および『Omnissa Access Connector のインストール』を参照してください。

     アップグレード中にオプションを構成することも、コネクタ インストーラを再度実行してアップグレード後に構成することもできます。

   • 24.12 Connector を使用すると、1 台のサーバに限定されるのではなく、複数の外部 Syslog サーバを指定してアプリケーションレベルのイベント メッセージを保存できます。Syslog サーバは、アップグレード中にウィザードの [Syslog サーバ情報の指定] ページで入力できます。

     次の形式を使用します。

     host:port,host:port,host:port

     host は、Syslog サーバの完全修飾ドメイン名または IP アドレス、port はポート番号です。例：

     syslog1.example.com:514,syslog2.example.com:601,syslog3.example.com:163

6. アップグレードが正常に完了したら、アップグレードされたサービスが Windows Server で実行されていることを確認します。

   サービスが実行されていない場合は、サービスを開始します。

   コネクタ サービスには、次の名前があります。

   • Access ディレクトリ同期サービス
   • Access ユーザー認証サービス
   • Access Kerberos 認証サービス
   • Access 仮想アプリケーション サービス

   例：

   

結果

コネクタのアップグレードが完了しました。新しいバージョンのコネクタがインストールされていることを確認するには、Windows Server の [コントロール パネル] > [プログラム] > [プログラムと機能] の順に移動して、表示されているコネクタのバージョンを確認します。

次のステップ

• Omnissa Access コンソールで、[統合] > [コネクタ] ページの更新アイコンをクリックし、アップグレードされたサービスがアクティブで、健全性ステータスが緑色になっていることを確認します。

  例：

  

  健全性ステータスが赤の場合は、サービスを再起動します。

• RSA SecurID（クラウド デプロイ）認証方法が元のインストールで構成されていて、コネクタをアップグレードする前にそれを削除した場合は、ユーザー認証サービスがインストールされているすべてのコネクタ インスタンスをアップグレードした後に、認証方法を再構成します。

  1. 複数の RSA Authentication Manager サーバ インスタンスを展開している場合は、ロード バランサの背後で構成し、ロード バランサの Omnissa Access 要件を満たす必要があります。「RSA SecurID ロード バランサの Omnissa Access の要件」を参照してください。

  2. プロキシ サーバにコネクタが構成されている場合は、RSA Authentication Manager サーバ用に構成された通信ポートがプロキシ サーバで開いていることを確認します。

  3. RSA セキュリティ コンソールで、コネクタが完全修飾ドメイン名 (FQDN) を使用して認証エージェントとして追加されていることを確認します。たとえば、connectorserver.example.com です。すでに FQDN ではなく NetBIOS 名を使用してコネクタを認証エージェントとして追加している場合は、FQDN を使用して別のエントリを追加します。新しいエントリの IP アドレス フィールドは空のままにします。古いエントリは削除しないでください。

  4. 元のインストールに含まれていたすべてのディレクトリの RSA SecurID（クラウド デプロイ）認証方法の構成を更新します。

     新しい構成の詳細については、「Omnissa Access での RSA SecurID 認証の構成」を参照してください。

  5. 元のインストールに含まれていたすべてのアクセス ポリシーに、RSA SecurID（クラウド デプロイ）認証方法を追加します。

     アクセス ポリシーは、[リソース] > [ポリシー] ページから編集できます。

• コネクタが FIPS モードで実行されていて RADIUS（クラウド デプロイ）認証方法を使用する場合、または使用する予定がある場合は、ユーザー認証サービスで RADIUS（クラウド デプロイ）認証を有効にします。

  1. INSTALL_PATH\User Auth Service\UserAuthService.xml ファイルに、次の JVM 引数を追加します。
     -Dorg.bouncycastle.jsse.enable_md5=true
     
     重要：行を追加する場所は、ファイル内の JVM 引数セクションです。それ以外の場所には追加しないでください。
  2. ユーザー認証サービスを再起動します。
  3. ユーザー認証サービスを実行するすべてのコネクタ インスタンスに対して、これらの手順を繰り返します。