第 1 世代テナント - Horizon Cloud - 既知の問題

このトピックでは、サービスの使用時に発生する可能性のある既知の問題および既知の回避策（ある場合）を示します。

重要： この情報は、第 1 世代の制御プレーンで第 1 世代のテナント環境にアクセスできる場合にのみ適用されます。 KB-92424 で説明されているように、第 1 世代の制御プレーンは提供終了 (EOA) となりました。詳細については、該当記事を参照してください。

このドキュメントのトピックでは、Horizon Cloud Connector の既知の問題について説明します。ただし、Horizon Cloud Connector を使用して Horizon ポッドを Horizon Cloud に接続する場合でも、これらの Horizon ポッド内で実行されているソフトウェアの既知の問題については、ポッドの Connection Server のソフトウェア バージョンに応じて、次の場所にあるリリース ノートを参照してください。

• バージョン 7.13 - Horizon 7 のドキュメントで入手できます。
• VMware Horizon 8 バージョン - Horizon のドキュメントで入手できます。

すべての Horizon Cloud のユーザーが本番環境で利用できる Image Management Service (IMS) 機能に関連する IMS の既知の問題については、『Cloud からの Horizon イメージの管理』の既知の問題のページを参照してください。

注： それぞれの既知の問題の末尾に記載された括弧内の数字は、VMware 内部の問題追跡システムに関連します。

ログインに関する既知の問題

バックスラッシュ (\) を含む My VMware アカウントのパスワードを正常に作成した場合でも、これらの認証情報を使用した Horizon Cloud へのログインが失敗する (2595757)

My VMware の認証情報を使用して Horizon Cloud にログインする場合、バックスラッシュを含むパスワードはサポートされません。サポートされている特殊文字の一覧を表示するには、my.vmware.com にログインし、プロファイルの [パスワードの変更] セクションに移動します。このページには、サポートされている特殊文字が表示されます。回避策：My VMware アカウントのパスワードを新しいパスワードにリセットし、新しいパスワードにバックスラッシュ (\) が含まれていないことを確認します。

Active Directory に関する既知の問題

管理コンソールで Active Directory に関連する操作を行わない限りプライマリ バインド アカウントのロックアウトが検出されない。(2010669)

この問題により、Web ベースの管理コンソールにログインした管理者は、ユーザーを割り当てに追加するために Active Directory を検索するなどの、Active Directory に関連する操作をユーザー インターフェイスで実行するまで、プライマリ バインド アカウントのロックアウト通知が表示されません。基盤となるサービスがロックアウトされたサービス アカウントを検出するのは、（ユーザーまたはグループを）認証または検索するために Active Directory との対話を要求するときのみです。回避策：なし。

Web ベースの管理コンソールがプライマリ ドメイン バインド アカウントのロックアウトまたはロック解除された状態を反映するのに最大 15 分かかる(2009434)

Active Directory へのシステムの接続オブジェクトは 15 分間キャッシュされます。この結果、プライマリ バインド アカウントがロックされてからシステムが管理者へ通知するまで 15 分かかる可能性があります。また、管理者がアカウントのロックアウト状態をクリアした後、システムがそのクリア済みのアカウントについての通知を停止するまでにも、15 分かかる可能性があります。回避策：なし。

Microsoft Azure のポッド内のファームでは、同じ Active Directory フォレスト内の別のドメインと同じファーム名を再使用すると、重複するサービス プロバイダ名 (SPN) が原因でドメイン参加が失敗する可能性がある(1969172)

Microsoft Windows Server 2012 R2 以降でのドメイン コントローラの新機能により、ドメイン コントローラでの重複する SPN チェックが原因でドメイン参加が失敗します。Microsoft のナレッジベースの記事 KB3070083を参照してください。回避策：

• ファーム名を再使用しないようにします。
• Microsoft のナレッジベースの記事の説明に従って、Active Directory ドメインでの重複する SPN チェックを無効にします。

Azure AD Domain Services を使用している場合、Active Directory の登録ワークフローはドメインへの参加ステップで失敗し、パスワードのリセット権限がないというエラーが発生します。(2218180)

Horizon Cloud チームは、ポッドで Azure Active Directory (AD) ドメイン サービスを使用するときに、他の Active Directory ドメインのデプロイのときと同じように、必要なドメイン参加アカウント権限を追加できることを確認しました。組み込みコンテナ AADDC コンピュータについて説明した Microsoft のドキュメント トピック Azure AD Domain Services のマネージド ドメインに組織単位 (OU) を作成するを参照してください。また、このトピックの冒頭の、Azure AD Domain Services とのパスワード ハッシュ同期の有効化に関する重要な注意事項も参照してください。ドメイン参加サービス アカウントの権限を設定する前に、ドメイン参加サービス アカウントの Azure AD Domain Services へのパスワード ハッシュ同期の有効化に関する Microsoft のドキュメントに従うことが重要です。Microsoft のドキュメントに従っても Active Directory の登録ワークフローでドメイン参加権限エラーが発生する場合は、VMware サポートに連絡し、問題レポート番号 2218180 について問い合わせてください。

Microsoft Azure サブスクリプションに関連する既知の問題

Horizon Universal Console を使用してポッドの Azure サブスクリプション設定のプライベート キーを更新した後、新しい認証情報を有効にするにはポッド マネージャ仮想マシンを再起動する必要がある（2979394、3007687、3017415）

この既知の問題により、コンソールの [サブスクリプションの管理] ウィンドウで [アプリケーション キー] 設定を編集して保存した後、仮想マシンのオペレーティング システムで管理サービスが再開されるまで、新しく入力したプライベート キーがポッド マネージャ仮想マシンで有効になりません。管理サービスが再起動されない場合、サービスがサブスクリプション内のリソースを操作するために使用する API 呼び出しが失敗し始めます。回避策：ポッドのサブスクリプション プライベート キーを何らかの理由（有効期限が近づいている、または有効期限が切れているなど）で更新する必要がある場合、サービス リクエストを開いて、VMware のサポートと Horizon Cloud オペレーション チームの支援を受け、一連の手順が正常に完了するようにします。概要レベルでは、手順は次のとおりです。

1. Azure ポータルで、新しいプライベート キーを生成します。
2. Horizon Universal Console で、デプロイされた Horizon Cloud ポッドに関連付けられたサブスクリプション情報の変更、修正、更新ページの説明に従って、標準の手順に従って、古いキーに関連付けられているポッドで使用されるプライベート キーを更新します。
3. 両方のポッド マネージャ仮想マシンで管理サービスの再起動を実行するように VMware のサポートに依頼します。

管理サービスを再起動する特定のコマンドを実行できるのは VMware チームだけであるため、ここでコマンドを公開することはできません。これらのチームは、社内の問題 3007687-update-9 を参照できます。

Cloud Connector に関連する既知の問題

Connection Server Monitoring Service (CSMS) のステータスが、 Horizon Cloud Connector 構成ポータルの [健全性] 領域に [準備ができていません] と表示される (3236634)

「 VMware KB91124」で説明されているように、 Horizon Cloud Connector バージョン 2.3 の場合、 Horizon Cloud Connector アプライアンスの再起動後、またはアプライアンスの Kubernetes クラスタの再起動後に、CSMS のステータスが [準備ができていません] と表示されます。

この問題は、バージョン 2.4 以降の Horizon Cloud Connector で解決されています。以前のバージョンでこの問題を回避するには、ナレッジベースの記事に記載されている手順に従ってください。

証明書の有効期限の問題 (3083444)

Horizon Cloud Connector バージョン 2.4 より前のバージョンの証明書には、アプライアンスのデプロイ時から 1 年で有効期限が切れるという問題が見つかりました。この証明書の有効期限が切れると、 Horizon Cloud Connector は Horizon Cloud 制御プレーンに接続できなくなり、 Horizon Cloud Connector によって提供されるクラウドベースのサービスが動作不能になります。修正の詳細と手順については、 KB90505 を参照してください。

Horizon Cloud Connector バージョン 2.4 以降では、期限切れ前に証明書が自動的に更新されます。

OVF テンプレートのデプロイ時に [プロキシなし] フィールドで指定されたプロキシなしのホスト構成は、デプロイされたアプライアンスに保存されない（2454245、2466306、2467017、DPM-5388）

この問題は、 Horizon Cloud Connector バージョン 1.6 以降では解決されています。vSphere 環境で [OVF テンプレートのデプロイ] ワークフローを実行するときに、プロキシなしのホスト構成を [プロキシなし] フィールドに指定するオプションがあります。ただし、この既知の問題により、入力した設定はデプロイされたアプライアンスの構成ファイルにキャプチャされません。その結果、デプロイされたアプライアンスは、指定されたプロキシなしのホスト設定を考慮しません。

Horizon Cloud ポッドのゲートウェイ構成に関する既知の問題

ゲートウェイ構成で Syslog サーバ設定を有効にするための Horizon Universal Console 機能は、デフォルトでオフになっています。（3005985、3023935、3026855）

Syslog サーバ情報を使用して Unified Access Gateway 構成を更新するシステムの API 呼び出しで特定された問題により、以前にリリースされた機能はコンソールで使用しないよう切り替えられています。回避策：なし。

Universal Broker 関連の既知の問題

Horizon Cloud Connector の Horizon Universal Broker クライアントは、アプライアンスが最初にデプロイされた後でコネクタ アプライアンスに対して行ったプロキシ関連の更新を使用しない (HD-35551)

この問題は、 Horizon Cloud Connector バージョン 1.6 以降では解決されています。コネクタ アプライアンスの Horizon Universal Broker クライアントは、アプライアンスの初回起動時にプロキシの詳細を取得します。初回の起動は、OVF テンプレートをデプロイした後、アプライアンスを初めてパワーオンしたときにのみ実行されるため、アプライアンスのプロキシ設定に対するその後の変更は、Horizon Universal Broker クライアントによって使用されません。この既知の問題と OVF テンプレートのデプロイ中のプロキシなしの構成に関する上記の既知の問題の存在により、Horizon Universal Broker に関連するホストをプロキシなしのホストとして設定できなくなります。

ブラウザの Horizon Client または Horizon HTML Access が Universal Broker への接続を開始すると、エラー メッセージ「Connection Server への接続に失敗しました」が表示される (2714266)

この問題は、エンド ユーザーのデスクトップを仲介するために Universal Broker を使用するように構成されたテナント内でマニフェスト 2632.x を実行している Microsoft Azure の Horizon Cloud ポッドに影響します。この問題のもう 1 つの兆候は、次の両方が同時に発生することです。

• デスクトップ仮想マシンが存在するポッドの詳細ページで、ポッド マネージャ仮想マシンの健全性がすべてのポッドのポッド マネージャ仮想マシンに対して「エラー」として報告される。
• ブラウザの Horizon Client または Horizon HTML Access が Universal Broker への接続を開始すると、エラー メッセージ「このデスクトップは現在使用できません。後でもう一度このデスクトップへの接続を試みるか、システム管理者にお問い合わせください。」と表示される。

この問題は、ポッド マネージャ インスタンスが再起動された場合に、マニフェスト 2632.x を実行している Microsoft Azure の Horizon Cloud ポッドで断続的に発生する可能性があります。ポッド マネージャ インスタンスが再起動されたとき（まれな、通常ではない状況）、ポッド マネージャ インスタンスがパワーオンされ、Universal Broker がポッドへの接続を試みた後に、認証された接続を確立できない場合があります。回避策：なし。このような状況が発生した場合は、サービス リクエストを開き、内部問題レポート番号 2714266 を伝えて、サポートを依頼します。

マニフェスト 2747.x 以降のポッドでは、この問題は解決されています。

イメージ、ファーム、割り当てに関する既知の問題

ここに記載した既知の問題は Microsoft Azure にデプロイされたポッドに適用されます。

イメージの公開中にタイムアウト エラーが発生し、仮想マシンがパワーオンされたままになり、公開フローが正常に完了しない（2954270、2962049）

この問題は、公開プロセスの sysprep 手順を実行するときに発生する Microsoft Azure ハイパーバイザーの問題の結果です。この問題は、一部の Azure 仮想マシン モデルで発生します。詳細については、VMware ナレッジベースの記事 KB88343 を参照してください。

Microsoft Azure チームの推奨事項に基づいて、Horizon Cloud ユーザーに解決策を提供するために、サービスの自動化された [Marketplace からの仮想マシンのインポート] ウィザードで使用されるデフォルトの Azure 仮想マシン モデルは、サービスの v2204 リリースで変更され、GPU 以外の Windows 10 仮想マシン（単一セッションとマルチセッションの両方）の自動インポートに Standard_DS2_v2 モデルが使用されます。

• シングルポッド イメージの場合、自動化のデフォルトの仮想マシン モデルは、以前に使用された Standard_D4_v3 仮想マシン モデルから、Standard_DS2_v2 を使用するように変更されました。
• マルチポッド イメージの場合、自動化のデフォルトの仮想マシン モデルは、以前に使用された Standard_D2_v2 モデルから、Standard_DS2_v2 を使用するように変更されました。

v2204 リリースの時点で、ポッドの Azure サブスクリプションに Azure DSv2 シリーズの割り当てを含めてください。

Microsoft Azure サブスクリプションで仮想マシンとその関連リソースが完全に削除されないことがあります。(2824239、2681761、2750176)

この問題は、ポッド マニフェスト 2915.x 以降で解決されています。以前のマニフェストのポッドでこの問題が発生すると、VDI 割り当ての拡張などの問題が発生する可能性があります。この問題は、Microsoft の Azure Resource Manager (ARM) の問題と、Microsoft Azure クラウドの複数のリージョン間でリソースのステータスを複製する際の遅延が原因で発生します。この Microsoft ARM の問題により、これらの仮想マシン関連リソースの一部が削除されずに残り、Azure サブスクリプションの仮想マシンに接続されないことがあります。このような接続されていないアイテムの例として、ディスクや NIC があります。回避策：この問題は、2915.x 以降のマニフェストを実行しているポッドで解決されています。この問題が発生した場合は、サービス リクエスト (SR) を発行して、古いデータのクリアに関するサポートを要求し、ポッドのアップグレードをスケジュールして問題の再発を防止してください。SR を発行する手順については、 ナレッジベースの記事 KB2006985を参照してください。

Microsoft Azure Government クラウド サブスクリプションにデプロイされたポッドの場合、ファームとデスクトップ割り当てでディスク暗号化機能を使用すると失敗する。(2572579)

ポッドが Microsoft Azure Government クラウドにある場合、ディスク暗号化機能を選択してファームまたは VDI 割り当てを作成しようとすると、エラー Azure error encrypting the VM により、作成プロセスが失敗します。回避策：なし。

既存のファームの [サーバ] タブでは、すべてのユーザー ログイン モードの選択によって、Horizon Agent を更新する必要があることを示すエラー メッセージが表示されます。(2528295)

管理コンソールを使用してユーザー ログイン モードを設定するには、ファーム仮想マシンで実行されているエージェント バージョン 20.1.0 の検出に依存します。ただし、既存のファーム仮想マシン内のエージェントを更新するために使用するクラウド制御プレーンでは、そのバージョンのエージェントはまだ利用できないことがあります。回避策：なし。エージェントの 20.1.0 バージョンがクラウド プレーンで使用可能で、ポッドがそのエージェントのバージョンを使用できるマニフェスト バージョンに更新された場合、ユーザー ログイン モードの選択を使用するために、ファーム仮想マシンをそのエージェントに更新できます。

大規模なフローティング VDI デスクトップ割り当ての一部のデスクトップ仮想マシンで、エージェントのステータスが不明として報告されることがある(DPM-3201)

多数のデスクトップ仮想マシンがあるフローティング VDI デスクトップ割り当てでは、既知の問題により、Horizon Agent の Blast サービスや Microsoft Azure サービスなどの一部の Windows サービスが起動しない、または起動に時間がかかることが原因で、これらのデスクトップ仮想マシンの一部において不明なエージェント状態になる可能性があります。その結果、管理コンソールで、エージェントのエラーが報告されるとともに、これらのデスクトップ仮想マシンの [エージェントのステータス] 列に「不明」の状態が表示されます。回避策：コンソールで、 [再起動] アクションを使用して、これらの仮想マシンを再起動します。

[Marketplace からの仮想マシンのインポート] ウィザードでデスクトップ環境が有効にならないまま、Windows Server 2012 イメージが作成される。(2101856)

既知の問題により、Windows Server 2012 オペレーティング システムでのイメージの作成で自動化された [Marketplace からの仮想マシンのインポート] ウィザードを使用する場合、結果として生成されるイメージでは Desktop Experience が有効にされていません。回避策：結果として生成されるイメージに Desktop Experience を表示するには、結果として生成されるイメージで Desktop Experience を手動で有効にする必要があります。Windows Server 2012 オペレーティング システムでは、Horizon Agent をスキャナ リダイレクト オプション付きでインストールするには Desktop Experience がオペレーティング システムで有効にされていることが必要であることにも注意してください。

インポートされた仮想マシンを公開（シーリング）しようとすると、プロセスがタイムアウトになる、または sysprep の障害により公開が失敗する（2036082、2080101、2120508、2118047）

インポートされた仮想マシンで [デスクトップへの変換] をクリックし、公開済み（シールド状態）のイメージにするためにその仮想マシンについて [公開] をクリックすると、その仮想マシンに対して多くの処理が行われます。その処理には、Windows System Preparation (sysprep) プロセスの実行、仮想マシンのシャットダウン、電源オフなどが含まれます。Windows sysprep プロセスおよび仮想マシンのカスタマイズについての業界内で既知の問題により、公開プロセスはさまざまな原因で失敗することがあります。[アクティビティ] 画面には、「タイムアウト エラー: 仮想マシンがパワー オフするのを 20 分間待機しました。(Timeout Error Waited 20 minutes for virtual machine to power off.)」のようなメッセージ、およびその他の sysprep 失敗メッセージが表示されます。

一般的に、[Marketplace からの仮想マシンのインポート] ウィザードを使用して仮想マシンを作成し、ウィザードの [Windows イメージを最適化] トグルで [はい] を選択すると、このような sysprep 問題を回避できます。このオプションを使用しなかったインポートされた仮想マシンでこのエラーが発生している場合や、その仮想マシンを手動で作成した場合は、Microsoft のナレッジベースの記事 KB2769827、Microsoft MVP 記事 615 を参照して、イメージの公開時に sysprep 問題が発生する確率を最小限に抑えるためのイメージ仮想マシンの構成に関するベスト プラクティスを確認してください。sysprep の問題が解決されない場合は、自動化された [Marketplace からの仮想マシンのインポート] ウィザードを使用して sysprep の問題の変更を削減する方法につて、記事[Marketplace からの仮想マシンのインポート] を使用する場合の Windows イメージの最適化の決定および[デスクトップのインポート] ウィザードを使用する場合の [Windows ストア アプリを削除] オプションの使用を参照してください。タイムアウト エラーが [アクティビティ] 画面に表示された場合、この回避策を [イメージ] 画面で試行し、そのイメージで [デスクトップへのイメージの変換] アクションを使用します。[アクティビティ] 画面に、デスクトップへのイメージの変換が正常に完了したと示されている場合は、[インポートされた仮想マシン] 画面に移動します。仮想マシンに接続し、ナレッジベースに記載されているベスト プラクティスを適用します。[インポートされた仮想マシン] ページに仮想マシンがパワーオンされたことを示す画面が表示されたら、仮想マシンを選択して [イメージに変換] をクリックして、公開プロセスを再度実行します。

ファームの作成中に、サーバ仮想マシンがカスタマイズの手順から先に進めなくなる場合がある(2010914, 2041909)

ファームのサーバ仮想マシン上での sysprep プロセスで、 tiledatamodelsvc という名前の Windows サービスにより、sysprep が、sysprep のカスタマイズ プロセスの完了に必要な Windows ファイルにアクセスできなくなることがあります。この結果として、ファームのサーバ仮想マシンはカスタマイズ ステップ以降に移動できません。sysprep エラー ログに、「Error SYSPRP setupdigetclassdevs failed with error 0」という行が含まれています。回避策：この問題が発生し、sysprep エラー ログ ファイルにそのエラー メッセージがある場合は、イメージの tiledatamodelsvc サービスを停止して無効にすることを試してください。その後に、ファームを作成します。

イメージを複製した後や Microsoft Azure でイメージを手動で作成した後に、エージェントのステータスが [インポートされた仮想マシン] 画面で「定義されていません」として表示される(2002798)

公開済みのイメージのクローンを作成するために [複製] ボタンを [イメージ] 画面で使用する場合や、Microsoft Azure でイメージ仮想マシンを手動で作成する場合に、結果として生成される仮想マシンが [インポートされた仮想マシン] 画面のリストに表示されます。この問題により、仮想マシンが完全にパワーオンになっているときでも、エージェントのステータスが「定義されていません」として表示されることがあります。しかし、仮想マシンを選択して公開するために [イメージへの変換] を選ぶと、ユーザー インターフェイスでエージェントが「アクティブ」状態であると報告されます。回避策：なし。 [エージェント ペアリングをリセット]、 [新しいイメージ] または [イメージに変換] のワークフローでエージェントが「アクティブ」であると報告される場合は、[インポートされた仮想マシン] 画面での「未定義」ステータスを無視してかまいません。

Microsoft Azure 内のポッドの App Volumes に関連する既知の問題

ここに記載した既知の問題は Microsoft Azure にデプロイされたポッドに適用されます。

異なる時刻にキャプチャされた同じファイル名を持つアプリケーション パッケージ（.vhd ファイル）を同じ場所（ファイル共有）にアップロードすると、ユーザーがログインしたときに App Volumes サービスがアプリケーションを VDI デスクトップに接続できなくなる (2783560)

App Volumes がアプリケーション パッケージ（.vhd ファイル）をキャプチャするたびに、システムは一意の GUID を生成してボリュームやキャプチャ セッションを識別します。以前にアップロードしたファイル名 (.vhd) を使用して、Horizon Cloud Azure ポッドのステージング ファイル共有にアプリケーション パッケージをアップロードすることを試みると、Horizon Cloud Azure ポッドとクラウド サービスにすでに存在する GUID 間で不一致が発生します。

Horizon Cloud Azure ポッドで実行されている App Volumes Manager サービスは、ファイル共有からアプリケーション パッケージを定期的にインポートします。Horizon Universal Console のインポートの [インベントリ] > [アプリケーション] ページからアプリケーションをインポートすることを試みると、新しくインポートされたアプリケーション パッケージとそれらに対応する GUID が、Horizon Cloud Azure ポッドを実行している App Volumes Manager サービスにある GUID と一致しません。この不一致のため、割り当てられたアプリケーションは資格のあるユーザーに接続されません。

コンソールの App Volumes 割り当てから一部のユーザーまたはグループを削除すると、割り当て内の残りのユーザーまたはグループの一部から資格が削除される場合がある (2704889)

この問題により、一連のアプリケーションと指定されたユーザーまたはグループを含む App Volumes 割り当てを作成し、その割り当てを編集して特定のユーザーまたはグループをいくつか削除したシナリオにおいて、その割り当てに残っている構成されたユーザーとグループの一部に対して、資格が付与されたデスクトップでアプリケーションが表示されません。

この問題はポッド マニフェスト 2747 以降で解決されましたが、以前のバージョンのマニフェストのポッドでこの問題が発生する可能性があります。この問題が発生した場合は、必要なアプリケーションとユーザーとグループを使用して新しい App Volumes 割り当てを作成し、以前に作成した App Volumes 割り当てを削除することで問題を回避できます。

Microsoft Azure に複数のポッドがある環境では、プロセスの完了後に、キャプチャ プロセスが不明な状態になることがある。(2600573)

環境内に App Volumes を使用している複数のポッドがある場合、キャプチャ プロセスの実行後に、仮想マシンのキャプチャ プロセスが完了しているにもかかわらず、コンソールでキャプチャが不明な状態であることが示されます。この問題を回避するには、 [インベントリ] > [アプリケーション] > [新規] > [インポート] を使用してアプリケーション パッケージを再インポートします。その結果、アプリケーション パッケージは個別のアプリケーションとして正常にインポートされ、その後の割り当てとアプリケーション起動が機能します。

Microsoft Windows 10 Enterprise のマルチセッション展開で、別のユーザーが同じマシンにログインすると、印刷ジョブが終了する場合がある。

この環境では、プリンタ ドライバを含むアプリケーション パッケージ割り当てを持つユーザーが初めてログインすると、そのマルチセッション マシン上の別のユーザーで進行中の印刷ジョブがエラー状態になる場合があります。この問題を回避するには、数分以上待って印刷ジョブが終了してから、印刷ジョブを再試行します。関連するベスト プラクティス情報については、『 Horizon Cloud テナント環境およびオンボーディング ポッドの管理』ガイドを参照してください。

Microsoft Windows 10 Enterprise マルチセッション展開で、アプリケーション パッケージが割り当てられていないユーザーがアプリケーションのイメージを受け取る

この環境では、プロビジョニング中にアプリケーションの自動更新をオフにしないと、マルチセッション デスクトップのすべてのユーザー（アプリケーションを割り当てられたユーザーだけではない）にデスクトップ ショートカットやアプリケーション バイナリの形式など、アプリケーションの更新された部分が誤って表示されることがあります。この問題を回避するには、自動更新サービスを使用するアプリケーションの場合、アプリケーション サービス名をマルチストリング svservice レジストリ構成 DisableAppServicesList に追加して、自動更新サービスが開始されないようにします。関連するベスト プラクティス情報については、『Horizon Cloud テナント環境およびオンボーディング ポッドの管理』ガイドを参照してください。

エージェントのアップデートに関連する既知の問題

ここに記載した既知の問題は Microsoft Azure にデプロイされたポッドに適用されます。

Windows Update が保留中になっているイメージに対してエージェントを更新しようとすると、更新プロセスが失敗することがある(2234964)

イメージに対して Windows OS のアップデートが必要な場合、OS 以外のマイナーなアップデートの場合とは対照的に、OS リソースがオフラインになりエージェントの更新で使用できなくなることがあります。回避策：Windows のアップデートが完了するまで待ってから、エージェントの更新を再試行します。すべての Windows アップデートが完了したことを確認するには、イメージをオフラインにし、すべての保留中のアップデートを実行し、エージェントの更新を開始する前にイメージを再公開します。

関連する既知の問題のレポートと監視

ここに記載した既知の問題は Microsoft Azure にデプロイされたポッドに適用されます。

ユーザー アクティビティ レポートで、週の平均（時間）の表示が直感的でない(1817065)

この問題により、週の統計は時間に合わせて変動します。これは、計算ロジックが現在の週の期間を 7 で除算し、1 週間への切り上げを行わないことが原因です。たとえば、直近の 30 日間を選択すると、完了した週のデータは変更されませんが、現在の週のデータは 7 で除算されます。現在のロジックは、週の平均（時間）= 1 日の平均（時間）* 7 日であるため、直近の 30 日間の週平均 =（合計期間/30日）* 7 日となります。回避策：なし

[デスクトップの健全性] レポートで、ファーム名または VDI デスクトップ割り当て名の変更後 1 時間経過するまで、その新しいファーム名または VDI デスクトップ割り当て名が反映されない(1756889)

ファーム名または VDI デスクトップ割り当て名を変更すると、[デスクトップの健全性] レポートの [割り当て] ドロップダウン メニューおよび [割り当て] 列で新しい名前が反映されるのに 1 時間かかります。回避策：新しい名前がレポートに表示されるまで 1 時間お待ちください。

[レポート] のユーザー インターフェイスの画面からエクスポート可能な一部の CSV ファイルのフォーマットが画面上の表と一致しない。(2015500)

一部の [レポート] 画面のサブ画面で、表示されたデータを CSV 形式でエクスポートする機能が利用できます。この問題により、デスクトップの健全性、同時実行、セッション履歴のレポートからエクスポートされた CSV ファイルのフォーマットが、画面上に表示されるものと正確に一致しなくなります。たとえば、列の見出しが異なる場合や、CSV ファイルに画面上の表よりも多くのデータ列が含まれることがあります。回避策：なし。

ID 管理、Workspace ONE Access、True SSO に関連する既知の問題

ここに記載した既知の問題は Microsoft Azure にデプロイされたポッドに適用されます。

1763 より前のマニフェスト バージョンのポッドがマニフェスト 1763 以降に更新され、そのポッドの Unified Access Gateway インスタンスに 2 要素 RADIUS が構成されており、 Workspace ONE Access とも統合されている場合は、ブラウザを使用して Workspace ONE Access からデスクトップを起動すると、ユーザー名フィールドにあらかじめユーザーの UPN が入力された RADIUS ログイン フォームが表示されます。(2248160)

この症状は VMware Horizon HTML Access 4.10 でリリースされた変更が原因で発生します。以前の Horizon Cloud リリースの Microsoft Azure のポッドが Unified Access Gateway インスタンスと 2 要素 RADIUS 認証で構成されていて、 Workspace ONE Access を使用するようにそのポッドを構成した場合、以前はブラウザを使用して Workspace ONE Access からデスクトップを起動すると、RADIUS ログイン フォームでユーザー名とパスコードの入力が求められていました。これに応じて、エンド ユーザーはフォームにユーザー名とパスコードを入力していました。ただし、この既知の問題により、そのポッドをこのリリースにアップグレードした後に同じ手順を使用してデスクトップを起動すると、RADIUS ログイン フォームのユーザー名フィールドに、ドメイン ユーザーの UPN が事前入力されるようになります。これは、ブラウザを使用してデスクトップを起動する場合にのみ発生します。Horizon Client を使用する場合は発生しません。回避策：これが発生した場合、エンド ユーザーは事前入力されたユーザー名フィールドを消去して、自分自身の情報を入力することができます。通常、 Workspace ONE Access と統合されているほとんどの環境では、2 要素認証は Workspace ONE Access で構成され、基盤となる Unified Access Gateway インスタンスには構成されません。この場合、この問題は発生しません。

Horizon Client を使用して Workspace ONE Access から 2 台目のデスクトップを起動すると、「このデスクトップまたはアプリケーションを実行する権限がありません (You are not entitled to that desktop or application)」のメッセージとともに失敗することがある。(1813881, 2201599)

この症状は、次のような状況で発生します。ユーザーが、1 つのグループ資格を通じて 2 つの専用 VDI 割り当てに対する資格を保持している場合。ユーザーがログインすると、両方の専用 VDI デスクトップ割り当てが Workspace ONE Access に表示されます。ユーザーは Horizon Client を使用して最初のデスクトップを起動します。デスクトップが接続される。次にもう 1 つの割り当てから同じく Horizon Client を使用して別のデスクトップを起動する。この場合、ユーザーに資格がないというエラーが表示され、2 台目のデスクトップの起動が失敗します。ただし、これは 2 台目のデスクトップで最初の試行時にのみ見られる問題です。ユーザーがブラウザを使用して 2 台目のデスクトップを起動すると、以降、Horizon Client を使用した 2 台目のデスクトップの起動は成功します。回避策：この状況が起きた場合は、2 台目のデスクトップはブラウザで起動してください。

Workspace ONE Access で、Horizon Cloud 管理コンソールから設定したリモート アプリケーションの表示名が表示されない。(2131583)

この問題は Workspace ONE Access Connector バージョン 19.03 を使用することで解決されます。19.03 より前のバージョンの Workspace ONE Access Connector の既知の問題により、 Workspace ONE Access が Horizon Cloud から同期するリモート アプリケーションを表示すると、Horizon Cloud でリモート アプリケーションに設定した表示名が Workspace ONE Access に表示されません。Horizon Cloud が表示名を Workspace ONE Access に送信した場合でも、 Workspace ONE Access はリモート アプリケーションの launchID を代わりに使用します。その結果、 Workspace ONE Access はリモート アプリケーションの基底名を表示します。

ユーザー インターフェイスに関する既知の問題

既知の問題に特に記載がない限り、ここに記載されている既知の問題は、Microsoft Azure にデプロイされているポッドに適用されます。

セッション ダッシュボードで表示されるログイン セグメント チャートにデータがない。

この問題は、すべてのタイプのポッドに適用されます。VMware Logon Monitor サービスにより、セッション ダッシュボードに表示するログイン セグメント チャートのデータが提供されます。ただし今回のリリースでは、VMware Logon Monitor の使用がサポートされず、Horizon Agents Installer では、対象となるすべてのインストールで VMware Logon Monitor サービスがデフォルトで無効になります。このため、ログイン セグメント チャートで表示可能なデータがないと報告されても、セッション ダッシュボードにはログイン セグメント チャートが表示されることになります。回避策：なし。

1 つのブラウザ タブで管理コンソールを使用するときに、同じブラウザの別のブラウザ タブにある切断されたデスクトップを起動しようとすると、HTML Access ポータルもログオフされ、HTML Access ポータル自身に再度ログインしなければならない。(2118293)

通常、デスクトップを起動し、デスクトップからログアウトせずに切断すると、HTML Access ポータル自身にログインされたままになり、HTML Access ポータルの認証情報を入力しなくても切断されたデスクトップに再接続できます。この問題のために、ブラウザ内の 1 つのブラウザ タブでコンソールにログインし、別のブラウザ タブを使用して HTML Access ポータルにログインしてデスクトップを起動すると、そのデスクトップから切断して再度接続する際に、HTML Access ポータルはログオフします。その後、そのデスクトップに再接続するには、HTML Access ポータルの認証情報を再入力する必要があります。回避策：この問題を回避するには、HTML Access ポータルのある場所とは別のブラウザ ウィンドウを使用して管理コンソールにログインします。この動作は、HTML Access ポータルを使用しているのと同じブラウザ ウィンドウのブラウザ タブでコンソールにもログインしている場合にのみ発生します。

特定のユーザーの [ユーザー カード] 画面で、VDI 専用デスクトップ割り当てが、ユーザーがその割り当てから専用デスクトップを初めて起動した後に [割り当て] タブから削除される(1958046)

ユーザーが Active Directory グループとしてではなく、個々のユーザーとして VDI 専用デスクトップ割り当て内で指定されると、ユーザーがその割り当てから専用デスクトップを初めて起動するまで、そのユーザーのみの VDI 専用デスクトップ割り当てが [ユーザー カード] 画面の [割り当て] タブに表示されます。ユーザーがその割り当てから VDI 専用デスクトップを最初に起動すると、ユーザー カードの [割り当て] タブには、そのユーザーの VDI 専用デスクトップ割り当てが表示されなくなります。ユーザーの最初の起動により、そのユーザーは割り当てによって定義された基盤となるプールから特定の専用デスクトップを要求し、システムはその特定の専用デスクトップをユーザーにマッピングします。このマッピングにより、特定の専用デスクトップは「割り当て済み」の状態になり、そのユーザーのユーザー カードの [デスクトップ] タブに表示されます。

回避策：この場合、特定のユーザーに割り当てられた起動済みの VDI 専用デスクトップを表示するには、ユーザー カードの [割り当て] タブではなく、[デスクトップ] タブを使用します。そのユーザーとデスクトップのマッピングが実行される特定の VDI 専用デスクトップ割り当てを見つける必要がある場合は、ユーザー カードの [デスクトップ] タブからデスクトップ名を取得し、上部バナーにある仮想マシン別の検索機能を使用して、特定のデスクトップ仮想マシンをリストします。仮想マシン別の検索結果で名前をクリックし、該当の専用デスクトップがある特定の割り当てページを開きます。これで、割り当ての詳細からユーザーを見つけることができます。

以前にオプションを選択して [新機能] 画面が表示されないように設定した後も、[新機能] 画面が表示される(2075825)

この問題は、すべてのポッド タイプの環境で発生します。この問題のため、ブラウザのキャッシュをクリアするか、以前に [新機能] 画面を表示しないというオプションを選択したブラウザとは別のブラウザを使用すると、管理コンソールにログインしたときにこの画面が表示されることがあります。[新機能] 画面を表示するかどうかのフラグは、ユーザーごとに保存されるのではなく、ブラウザのローカル キャッシュに保存されます。回避策：なし。

イメージ作成のプロセスが完全に完了していない場合でも、[はじめに] 画面の [イメージの作成] 手順に [完了] と表示される(2100467)

この問題のため、[イメージの作成] 手順が完了していないのに [完了] と表示されます。回避策：[アクティビティ] 画面を使用して、イメージの作成プロセスが完了したことを確認します。

管理コンソールを使用しているときに、実際のテキスト文字列の代わりにプレースホルダが表示される場合や、ページのボタンをクリックしても何も起こらない場合がある。(2045967)

この問題は、すべてのポッド タイプの環境で発生します。VMware は Web ベースのコンソールをホストするクラウド内の管理環境を定期的にアップデートします。この問題が発生するのは、最新のクラウド内アップデートよりも前に、ブラウザで静的コンテンツがキャッシュされているときです。これは一時的な問題で、ブラウザのキャッシュがクリアされると解決されます。回避策：コンソールからログアウトし、ブラウザのキャッシュをクリアしてから、ブラウザを再起動してコンソールに再びログインしてください。

エンド ユーザーが Workspace ONE Access を使用してアプリケーションにアクセスすると、アプリケーション名が小文字で表示される。(1967245)

Horizon Cloud 環境が Workspace ONE Access に統合されている場合、エンド ユーザーは Workspace ONE Access を使用して割り当てられたデスクトップおよびアプリケーションにアクセスします。この既知の問題により、アプリケーション名に大文字が使用されていても、表示されるアプリケーション名はすべて小文字になります。この制限は、 Workspace ONE Access が古い Horizon Cloud REST API を使用して Horizon Cloud から起動 ID を作成する方法に関係します。回避策：なし。

デスクトップの健全性レポートに対して報告され、デスクトップの健全性アラートのために使用されるメモリ使用量の割合は、コミットされているメモリの割合に基づく。これは、物理メモリとページファイルのサイズの合計に等しく、物理メモリのみの割合に基づくものではない。(2015772)

デスクトップ仮想マシンでコミットされたメモリは物理メモリにページファイル サイズを加えたものとして計算されます。デスクトップのメモリ使用量の割合を計算するときに、システムはその合計（物理メモリとページファイルのサイズ）に使用される割合を示します。デスクトップの健全性アラートと、デスクトップの健全性レポート内のメモリ使用率レポートの両方で、その割合の計算が使用されます。ただし、デスクトップ仮想マシンにログインして Windows タスク マネージャーを開き、デスクトップの Windows オペレーティング システムのメモリ使用量を表示する場合、Windows タスク マネージャーには物理メモリのみに基づく割合が表示されます。このため、デスクトップの Windows タスク マネージャーに表示されるメモリ使用量の割合は、デスクトップの健全性レポートまたはデスクトップの健全性アラートに表示されるメモリ使用量の割合と一致しません。回避策：デスクトップの Windows タスク マネージャーによって報告されるメモリ使用量の割合と、コンソールのデスクトップの健全性レポートとデスクトップの健全性アラートでそのデスクトップについて報告されるメモリ使用量の割合の比較を実施する場合は、この差異を考慮します。

デスクトップ仮想マシンの CPU 使用率が 100% または 100% に近い場合に、デスクトップ アラートがトリガされない(1446496)

デスクトップ仮想マシンのアプリケーションなどによって仮想マシンの CPU 使用率が 100% に到達すると、CPU がビジー状態のため、デスクトップ エージェントは通常で Horizon Cloud に送信可能な量のデータ サンプルを送信することができません。返されるサンプル数が少ないことにより、デスクトップ アラートをトリガするためにシステムによって使用される計算に影響します。回避策：なし。

エンド ユーザー、Horizon Agent、Horizon Client 関連の既知の問題

ここに記載した既知の問題は Microsoft Azure にデプロイされたポッドに適用されます。

最近開いているオプション (またはクライアント タイプに基づく同等のオプション) を使用して Horizon Client から専用デスクトップを起動すると、専用デスクトップが正しく起動しないことがある (SR23422432704、HCS-39121)

さまざまな Horizon Client は、クライアントが以前に起動したデスクトップまたはリモート アプリケーションを記憶するメカニズムを提供します。エンド ユーザーは、資格が付与されているデスクトップとアプリケーションの完全なリストに移動することなく、以前に開いたデスクトップまたは公開アプリケーションを起動できます。

たとえば、Horizon Client for iOS と Horizon Client for Android では、[最近使用したアイテム] というラベルの付いた画面から、以前に起動したデスクトップやリモート アプリケーションにアクセスできます。『VMware Horizon Client for Mac 製品のドキュメント』で説明されているように、Horizon Client for Mac では、最近使用したデスクトップとリモート アプリケーションを開く方法として、クライアントの [ファイル ] > [最近使用したアイテムを開く] オプションを使用する方法と、Dock のアイコンを使用してクライアントを Dock に追加する方法の 2 つがあります。『VMware Horizon Client for Windows 製品のドキュメント』で説明されているように、Horizon Client for Windows には、ジャンプ リスト統合と呼ばれる GPO 設定があり、通常はデフォルトで有効になっています。これにより、ユーザーは Windows タスクバーの Horizon Client アイコンを使用して最近使用したデスクトップや公開アプリケーションに接続できます。

Horizon Cloud on Microsoft Azure によってプロビジョニングされた専用デスクトップの場合、最初のデスクトップの起動後に、Horizon Client がデスクトップの正しい ID を最近の起動として保存しないことがあります。

この問題により、エンド ユーザーが上記のクライアントの recent メカニズムのいずれかを使用してデスクトップを再度開くと、デスクトップが起動しないことがあります。

この問題は、Horizon Cloud on Microsoft Azure デプロイで Workspace ONE Access が使用され、Horizon Client がユーザーを Workspace ONE にリダイレクトして専用デスクトップの起動を調整する場合にも発生する可能性があります。エンド ユーザーが以前に Workspace ONE ポータルからデスクトップを直接起動したことがあり、その後、ユーザーがクライアントの recent メカニズムのいずれかを使用してデスクトップを起動しようとした場合、クライアントが起動を調整するために Workspace ONE にリダイレクトすると、この問題が原因でデスクトップが起動しないことがあります。

回避策：この問題が発生しないようにするには、常にクライアントの完全なデスクトップ リストからデスクトップを直接選択してデスクトップを起動するか、すべての起動を Workspace ONE ポータルから実行する必要があるように環境が構成されている場合は、Workspace ONE ポータル内でデスクトップを選択して起動を開始します。クライアントの recent メカニズムを使用しないでください（ [ファイル ] > [最近使用したアイテムを開く]、 [最近使用したアイテム] リスト、またはクライアントによって提供される recent メカニズムを使用しないでください）。

注： Horizon Cloud on Microsoft Azure デプロイで Workspace ONE リダイレクトが有効になっていて、エンド ユーザーが recent メカニズムを使用し、デスクトップの起動に失敗すると、起動に失敗したことを示す Workspace ONE 監査イベントが書き込まれます。

Microsoft Windows 10 Enterprise マルチセッション 2004 以降を実行している仮想マシンの場合、DPI の同期とディスプレイのスケーリング機能に問題がある（2587685、DPM-6352）

Microsoft Windows 10 Enterprise マルチセッション 2004 以降を実行している仮想マシンで現在の DPI をクエリできないため、これらの仮想マシンの当該機能は、Horizon Client ドキュメントに記載されているとおりに機能しません。DPI の同期とディスプレイのスケーリング機能は、PCoIP セッションの再接続では動作しません。DPI スケーリング機能は、Blast セッションの再接続では動作しません。回避策：セッションからログアウトし、ログインし直します。

Microsoft Windows 10 Enterprise クライアント オペレーティング システム 1903 以降を実行している仮想マシンの場合、DPI の同期とディスプレイのスケーリング機能に問題がある (2589129)

Microsoft Windows 10 Enterprise クライアント オペレーティング システム 1903 以降を実行している仮想マシンで現在の DPI をクエリできないため、PCoIP または Blast セッションを再接続すると、これらの機能が Horizon Client のドキュメントに記載されたとおりに動作しません。回避策：セッションからログアウトし、ログインし直します。

VMware HTML Access を使用して VDI デスクトップを起動するときに、接続解除に関するエラー メッセージが表示され、その後に起動に成功することがある(2243471)

VDI デスクトップ仮想マシンにはデフォルトのセッション接続タイムアウトが設定されており、タイムアウトに達するとセッションは切断されます。デスクトップを起動するときに、デスクトップのデフォルトのセッション接続タイムアウトに達した場合にエンド ユーザーの HTML Access セッションがタイムアウトすると、デスクトップで最初にそのエラーが発生し、デスクトップの起動を続行することがあります。回避策：なし。

VDI デスクトップ割り当てにディスク暗号化を選択していて、1 つまたは 2 つのコアの仮想マシンがあり、かつデスクトップの基盤となる仮想マシンの電源がオフの場合、Horizon Client の自動再試行オプションが接続できないことがある(2167432)

VDI デスクトップ割り当ての電源管理設定により、VDI デスクトップの仮想マシンの電源がオフの場合、仮想マシンの電源をオンにして準備完了になってから、エンド ユーザーがそのデスクトップに接続できるようになります。エンド ユーザーが VDI デスクトップ割り当ての仮想マシンへの接続を試みたときに仮想マシンがオフになっていると、システムはその仮想マシンでの起動を開始します。暗号化されていない仮想マシンの場合、通常、この仮想マシンは 10 分以内にクライアント接続を受け入れる準備を完了します。ただし、暗号化された仮想マシンに備えられているコアが 1～2 個の場合、1 つの接続に対する準備を完了するのに通常、10 分以上かかります。Horizon Client の [クライアントの再試行] オプションには 12 分間の上限が設けられています。 [クライアントの再試行] オプションではこの上限が適用されるため、デスクトップの基盤となる仮想マシンに電源が投入され、準備を実施している間、12 分以内に接続が完了する前に、エンド ユーザー側からクライアントに対して自動的に接続が再試行されると、クライアントの自動再試行が放棄されます。暗号化された仮想マシンでは通常、クライアント接続を準備するまでに 12 分以上要するため、エンド ユーザーは Horizon Client の自動再試行が失敗し、暗号化デスクトップ仮想マシンへの接続が完了しなかったと判断することがあります。回避策：VDI デスクトップ割り当てにディスク暗号化を設定する場合は、2 つ以上のコアを持つ仮想マシン モデルを選択します。また別の方法として、VDI デスクトップ割り当てにディスク暗号化が選択され、1 つの仮想マシン モデルに 1 つ以上のコアが選択されている場合、エンド ユーザーに対し、暗号化されたデスクトップの仮想マシンに [[クライアントの再試行]] オプションを使用すると、この問題が生じることがあるということを通知します。

専用 VDI デスクトップ割り当ての仮想デスクトップの場合、Horizon Client の [最近使用したアイテム] 画面でショートカット リンクをクリックしてもデスクトップが起動しないことがある(1813881、HD-3686、DPM-1140)

Horizon Client の iOS および Android バージョンの場合、[最近使用したアイテム] 画面に最近起動したデスクトップのリンクが表示されます。ユーザーが専用プールの仮想デスクトップを初めて起動するときに、デスクトップが通常どおり起動し、クライアントが [最近使用したアイテム] ページに起動アイコンを作成します。ユーザーがデスクトップを切断した後で [最近使用したアイテム] ページからデスクトップを起動しようとすると、起動アイコンがデスクトップ名の短縮バージョンを使用するため、デスクトップを起動できません。回避策：[最近使用したアイテム] 画面ではなく、クライアントのメイン画面からデスクトップを起動してください。

1976.0 マニフェスト バージョンのポッドとエージェント レベル 19.4 を実行しているファーム仮想マシン：HTML Access (Blast) および PCoIP プロトコルを使用している場合、ユーザーはデスクトップまたはリモート アプリケーション セッションから 1 時間後に切断されます。(2519400)

この問題は、Microsoft Windows 10 Enterprise マルチセッション システムの Microsoft ターミナル サービスの問題によるものです。Microsoft Windows 10 Enterprise マルチセッション オペレーティング システムに基づいた RDSH ファームからプロビジョニングされるセッション ベースのデスクトップおよびリモート アプリケーションの場合、エンド ユーザーが HTML Access (Blast) または PCoIP プロトコルを使用して既存のデスクトップまたはリモート アプリケーション セッションに再接続した後、1 時間が経過すると、ユーザーのセッションは強制的に切断されます。データが失われることはありません。ユーザーは再接続でき、セッションが切断時と同じ状態ですが、この動作が繰り返され、再接続されたセッションが 1 時間後にまた強制的に切断されます。

この問題は、Horizon Agents Installer (HAI) 20.1 以降を使用して解決されています。1976.0 ポッドが 1976.1 以降のマニフェストに更新されると、[Marketplace からの仮想マシンのインポート] ウィザードにより、この修正が適用されたエージェント ソフトウェアが自動的にインストールされます。ポッドのマニフェスト レベルがまだ 1976.0 にある場合、ウィザードを実行しても、問題のあるエージェント ソフトウェアがインストールされます。ただし、仮想マシンをシールすると、[イメージ] ページに青色のドットが表示されます。これはエージェントのアップデート機能を使用してエージェントを修正が適用されたレベルにアップデートできることを意味します。

マニフェスト バージョン 2298 より前のポッド：クライアントでプロトコルを切り替えるときに、[ログアウトして再接続] ではなく [接続] を選択すると、クライアントが応答しなくなることがあります。(2528014)

この問題は、マニフェスト 2298 以降に更新されたポッドで解決されています。この問題は、1 つのプロトコルを使用して RDSH ファームへのセッションを確立した後に、クライアントでプロトコルを切り替えると発生します。1 つのプロトコルを使用してデスクトップまたはアプリケーションを起動するときに、そのセッションを切断し、クライアントのメニューを使用して別のプロトコルに切り替え、同じデスクトップまたはアプリケーションを起動すると、クライアントは、「このデスクトップはサーバ上で開いていますが、異なるプロトコルを実行しています」というダイアログ ボックスを表示します。接続するか、ログアウトして再接続するかを選択できます。[接続] ボタンを選択すると、ダイアログが再度表示されます。もう一度 [接続] を選択すると、クライアントが応答しなくなります。

エージェントのアップデート機能を使用して 18.2.2 バージョンより前のエージェントを含むイメージを更新すると、アップデート プロセスが失敗することがある (2200962)

マニフェスト レベルが 965 以前のノードで作成したイメージで、この問題が生じることがあります。場合によっては、イメージの RunOnce レジストリに、エージェントのアップデート プロセスの実行を妨げる値が生じることがあります。回避策：エージェントのアップデートを再度実行し、[エージェントのアップデート] ウィザードの [コマンド ライン] タブで次のコマンド ライン引数を追加します。VDM_SUPPRESS_RUNONCE_CHECK=1