アップグレード後の構成

VMware Identity Manager 3.2.0.1 にアップグレードした後で、特定の設定が必要になる場合があります。

カスタマーエクスペリエンス向上プログラム

本製品は、VMware カスタマーエクスペリエンス向上プログラム（「CEIP」）に参加しています。CEIP を通して収集されるデータおよび VMware のその使用目的に関する詳細は、Trust & Assurance センター (https://www.vmware.com/jp/solutions/trustvmware/ceip.html) に記載されています。

VMware Identity Manager 3.2.0.1 にアップグレードして管理コンソールにログインすると、VMware カスタマーエクスペリエンス向上プログラムに参加オプションがバナーに表示されます。VMware の CEIP への参加を希望されない場合は、チェックボックスをオフにして OK をクリックします。

バナーは、OK をクリックするか閉じるまで表示されたままになります。CEIP は、アプライアンス設定 > テレメトリページからいつでも参加または中止していただけます。

Elasticsearch の移行

注:

この情報は、以前のバージョンからバージョン 3.2.x にアップグレードする場合に適用されます。3.2 から 3.2.0.1 にアップグレードする場合には適用されません。

検索と解析エンジンである Elasticsearch は、VMware Identity Manager に組み込まれ、監査、レポート、および検索に使用されます。以前のバージョンには Elasticsearch 1.75 が含まれていましたが、VMware Identity Manager 3.2.x には Elasticsearch 2.3.5 が含まれています。VMware Identity Manager 3.2.x へのアップグレード中に、Elasticsearch レコードが移行されます。

VMware Identity Manager アップグレードが完了すると、バックグラウンドジョブが開始し、Elasticsearch によって処理される既存の監査および検索レコードが、新しい形式に移行します。このプロセスの起動は、アップグレードが完了してから最大で 1 時間遅延することがあります。起動すれば、通常は完了まで時間はかかりませんが、レコード数によっては 1 〜 2 時間かかることがあります。

移行の進捗状況に関するメッセージは、/opt/vmware/horizon/workspace/logs ディレクトリにある analytics-service.log ファイルを参照してください。

移行が開始すると、The latest Audit schema version is 4.（最新の監査スキーマのバージョンは 4 です。）というメッセージが記録されます。
毎日のデータの移行によって、Re-indexing documents from（次の日付からドキュメントのインデックスを再作成します）で始まるメッセージが記録されます。
移行が終了すると、Audit schema check completed.（監査スキーマチェックが完了しました。）というメッセージが記録されます。

移行が完了するまでは、古いレコードのすべてまたは一部は使用できないため、ダッシュボードと監査レポートに古いレコードは表示されず、検索とオートコンプリート機能は使用できません。ただし、新しい監査レコードは移行とは関係なく生成および処理されるため、ダッシュボードおよび監査レポートには新規ログイン情報などが表示されます。新しい監査レコードが監査レポートに表示されない場合は、Elasticsearch クラスタの健全性をチェックします。

Elasticsearch クラスタの健全性をチェックするには：

ssh を実行してノードに接続し、次のコマンドを実行します。
curl http://localhost:9200/_cluster/health?pretty
"status" フィールドが "yellow" または "green" の場合は、analytics-service ログのエラーを確認します。"status" フィールドが "red" の場合は、マスターノードを再起動する必要があります。
マスターノードを再起動するには：
1. 次のコマンドを実行してマスターノードを特定します。
  curl http://localhost:9200/_cluster/state/master_node,nodes?pretty
2. "master_node" フィールドの値を探し、ノードのリストから一致する値を特定して IP アドレスを特定します。たとえば、このサンプル出力では、マスターノードは "Gq-ITVBKRJKz1816XqrRKw" で、その IP アドレスは "1.1.1.2" です。
```
{
   "cluster_name" : "horizon",
   "master_node" : "Gq-ITVBKRJKz1816XqrRKw",
   "nodes" : {
      "mzWHVMZuTXyFsO61NLpHnA" : {
         "name" : “Node1”,
         "transport_address" : “1.1.1.1:9300",
         "attributes" : { }
   },
   "Gq-ITVBKRJKz1816XqrRKw" : {
         "name" : “Node2”,
         "transport_address" : “1.1.1.2:9300",
         "attributes" : { }
   },
   "pkREX2D9R1a-lqf69PQMKQ" : {
         "name" : “Node3”,
         "transport_address" : “1.1.1.3:9300",
         "attributes" : { }
   }
}
```
3. ssh を実行してマスターノードに接続し、Elasticsearch を再起動します。
  service elasticsearch restart
4. Elasticsearch が再起動したら、クラスタの健全性を再度確認します。
  curl http://localhost:9200/_cluster/health?pretty
  コマンドは、最初に "yellow" ステータスを表示する場合があります。“green” ステータスが表示されるまで、コマンドを繰り返し実行します。

Elasticsearch マッピングの競合

インデックスにマッピングの競合があると、VMware Identity Manager 3.2.x の Elasticsearch 2.3.5 は起動しません。Elasticsearch マッピングの競合のチェックの手順に従ってアップグレード前にマッピングが競合するインデックスを削除しなかった場合、Elasticsearch は起動しません。

Elasticsearch のログファイル /opt/vmware/elasticsearch/logs/horizon.log には、影響を受けるインデックスについての次のようなメッセージが含まれています。

[2018-04-24 13:13:41,722][ERROR][bootstrap                ] Guice Exception: java.lang.IllegalStateException: unable to upgrade the mappings for the index [v3_2018-03-16], reason: [Mapper for [tenantId] conflicts with existing mapping in other types:

この問題を解決するには、すべての VMware Identity Manager ノードからインデックスを手動で削除します。

すべてのノードで Elasticsearch が停止していることを確認します。
service elasticsearch stop
すべてのノードでディスクからインデックスファイルを削除します。
rm -rf /db/elasticsearch/horizon/nodes/0/indices/<INDEX_NAME>
すべてのノードで Elasticsearch を再起動します。
service elasticsearch start

アップグレード後に検索が機能しない

アップグレード後に、監査レポートとダッシュボードが機能しているのに検索が機能しない場合は、検索インデックスが不正な可能性があります。

アップグレード中に、すべてのユーザー、グループ、およびアプリケーションは新しい検索インデックスに再インデックス処理されます。マッピングの競合の問題など、Elasticsearch に問題があった場合、再インデックス処理が正しく行われないことがあります。

この問題を解決するには、HZN Cookie 値を使用するゼロダウンタイムオプションまたはデータベース内の値を直接変更するダウンタイムオプションを使用して再インデックス処理を手動で実行します。

ゼロダウンタイムオプションを使用して手動で再インデックス処理を実行するには：

管理者ユーザー、つまり VMware Identity Manager を初めてインストールするときにシステムドメインに作成されるデフォルトの管理者として VMware Identity Manager サービスにログインします。
ブラウザの Cookie キャッシュから HZN Cookie の値を取得します。
たとえば、Firefox では次のように実行します：
1. オプション > プライバシーとセキュリティに移動します。
2. 履歴で、個々の Cookie を削除リンクをクリックします。
3. [Cookie] ダイアログボックスで、HZN を検索します。
4. 検索結果で HZN Cookie を選択し、その値をコンテンツフィールドからコピーします。

VMware Identity Manager ノードに ssh 接続し、次の REST 呼び出しを行い、<cookie_value> をブラウザから取得した HZN Cookie の値に置換します。

/usr/local/horizon/bin/curl -k -XPUT -H "Authorization:HZN <cookie_value>" -H "Content-Type: application/vnd.vmware.horizon.manager.systemconfigparameter+json" https://localhost/SAAS/jersey/manager/api/system/config/SearchCalculatorMode -d '{ "name": "SearchCalculatorMode", "values": { "values": ["REINDEX"] } }'

ダウンタイムオプションを使用して手動で再インデックス処理を実行するには：

すべてのノードで VMware Identity Manager サービスを停止します。
service horizon-workspace stop
ノードのいずれかで、次のコマンドを実行します。
hznAdminTool reindexSearchData
すべてのノードで VMware Identity Manager サービスを再起動します。
service horizon-workspace start

再インデックス処理が開始したことを確認するには、/opt/vmware/horizon/workspace/logs/horizon.log ファイルで次のようなメッセージを見つけます。

com.vmware.horizon.search.SearchCalculatorLogic - Keep existing index. Search calculator mode is: REINDEX

再インデックス処理は数分で完了します。

Log4j 構成ファイル

VMware Identity Manager インスタンスの log4j 構成ファイルを編集した場合、新しいバージョンのファイルはアップグレード中に自動的にインストールされません。ただし、アップグレード後、それらのファイルによって制御されるログは動作しません。

この問題を解決するには：

仮想アプライアンスにログインします。
.rpmnew サフィックスを持つ log4j ファイルを検索します。
find / -name "**log4j.properties.rpmnew"
見つかったファイルごとに、新しいファイルを .rpmnew サフィックスのない対応する古い log4j ファイルにコピーします。

セカンダリデータセンターアプライアンスのキャッシュサービス設定

セカンダリデータセンターを設定すると、セカンダリデータセンターの VMware Identity Manager インスタンスには、/usr/local/horizon/conf/runtime-config.properties ファイルの "read.only.service = true" エントリによって読み取り専用アクセスが設定されます。このようなアプライアンスをアップグレードすると、サービスは起動に失敗します。

この問題を解決するには：

仮想アプライアンスにログインします。
/usr/local/horizon/conf/runtime-config.properties ファイルに次の行を追加します。
cache.service.type = ehcache
サービスを再起動します。
service horizon-workspace restart

ロールベースのアクセス制御

VMware Identity Manager 3.2 ではロールベースのアクセス制御が導入されました。既知の問題については、VMware Identity Manager 3.2 リリースノートを参照してください。

Citrix 統合

VMware Identity Manager 3.2 での Citrix 統合では、すべての外部コネクタがバージョン 2018.1.1.0（3.2 リリースのコネクタバージョン）以降である必要があります。

Integration Broker 3.2 以降へもアップグレードする必要があります。

過去のリリースでの変更

バージョン 3.1 の変更

バージョン 3.1 以降では新しい機能が導入され、ユーザーグループの同期方法が変更されました。VMware Identity Manager 3.1 以降へのアップグレード後、アップグレード前に追加されたすべてのユーザーグループに対して資格が割り当てられていることを確認します。アップグレード後に追加された新しいユーザーグループは、リソースの使用資格がグループに付与され、アクセスポリシールールに追加されるまで（バージョン 3.2 以降の場合はグループのグループ > ユーザーページから手動で同期されるまで）、VMware Identity Manager サービスに同期されません。
資格が ALL USERS に設定されていて、アップグレード後に作成された新しいグループのユーザーがまだ同期されていない場合は、それらのユーザーは含められません。新しいグループの資格を追加します。
詳細については、VMware Identity Manager 3.1 へのアップグレード後のグループの同期方法を参照してください。
Citrix 公開リソースを VMware Identity Manager 3.1 に統合する場合は、Integration Broker 3.1 にアップグレードします。VMware Identity Manager 3.1 および VMware Identity Manager Connector 2017.12.1.0（3.1 リリースのコネクタバージョン）には、Integration Broker 3.1 が必要です。

バージョン 3.0 の変更

Citrix 公開リソースを VMware Identity Manager に統合する場合は、Integration Broker 3.0 にアップグレードします。VMware Identity Manager 3.0 および VMware Identity Manager Connector 2017.8.1.0（3.0 リリースのコネクタバージョン）は、Integration Broker の以前のバージョンと互換性がありません。

表 1. サポートされているバージョン
VMware Identity Manager または Connector のバージョン	サポートされる Integration Broker のバージョン
VMware Identity Manager 3.0	3.0
VMware Identity Manager Connector 2017.8.1.0（VMware Identity Manager 3.0 リリースのコネクタバージョン）	3.0
VMware Identity Manager 2.9.1 以前	2.9.1 以降
VMware Identity Manager Connector 2.9.1 以前	2.9.1 以降

Horizon デスクトップとアプリケーションを VMware Identity Manager に統合し、VMware Identity Manager クラスタを展開した場合は、Horizon 統合を再度構成する必要があります。
- Horizon リソースを保存して同期したプライマリコネクタで、すべての Horizon ポッドを削除してもう一度追加し、保存と同期をクリックします。
- Horizon リソース構成を保存したその他のコネクタで、すべての Horizon ポッドを削除してもう一度追加し、保存をクリックします。

3.0 より前のリリースの変更

VMware Identity Manager 2.9.1 以降での一括同期の変更
以前のバージョンでの一括同期は、データベース内の bulkSyncThreadLimitPerCPU=4 というグローバル構成パラメータによって、CPU ごとに 4 つのスレッドで処理されていました。
VMware Identity Manager 2.9.1 以降では、一括同期処理のスレッド数は CPU を基にしていません。それは絶対的な数で、デフォルトではノード上の CPU の数に一致します。
多数のユーザーとグループを同期し、アップグレード後に同期が遅れる場合は、bulkSyncSharedThreadCount というグローバル構成パラメータを設定してスレッド数を指定できます。
次の REST API を使用してデータベース内のスレッド値を設定し、ノードを再起動して変更を有効にします。
HTTP 要求：
```
Operation: PUT
URI: bulkSyncSharedThreadCount
```
HTTP ヘッダー：
```
Content-Type: application/vnd.vmware.horizon.manager.systemconfigparameter+json
Accept: application/vnd.vmware.horizon.manager.systemconfigparameter+json
Authorization: HZN <operator token>
```
要求の本文（たとえば 8 スレッドの場合）：
```
{
    "name": "bulkSyncSharedThreadCount",
    "values": {
        "values": [
            "8"
        ]
    }
}
```
新しいポータルのユーザーインターフェイスを有効にします。
1. 管理コンソールで、カタログタブの矢印をクリックして、設定を選択します。
2. 左ペインで新しいエンドユーザーポータル UI を選択して、新しいポータル UI を有効化をクリックします。
2 つのノードを使用してフェイルオーバーのためのVMware Identity Managerクラスタを設定している場合は、3 ノード構成に更新することを推奨します。これは、VMware Identity Managerアプライアンスに組み込まれた検索と解析エンジンである Elasticsearch の制限によるものです。2 つのノードをそのまま使用することもできますが、Elasticsearch に関連するいくつかの制限に注意してください。詳細については、『VMware Identity Manager のインストールと構成』の「フェイルオーバーと冗長性の構成」を参照してください。
VMware Identity Manager では、トランスポートレイヤセキュリティ (TLS) プロトコル 1.0 はデフォルトで無効になります。TLS 1.1 と 1.2 がサポートされています。
TLS 1.0 が無効になっているときは外部的な製品の問題が発生することが知られています。TLS 1.1 または 1.2 を使用するようにその他の製品の構成を更新することを推奨します。ただし、これらの製品が TLS 1.0 に依存している場合は、ナレッジベースの記事 2144805 の指示に従って、VMware Identity Manager で TLS 1.0 を有効にできます。

カスタマー エクスペリエンス向上プログラム