このドキュメント ページでは、デプロイされた Horizon Cloud ポッドを構成する VMware ソフトウェア コンポーネントのメンテナンスに関する重要な事項について説明します。
簡単な紹介
システムのメンテナンス アクティビティには、ポッドのソフトウェア コンポーネントの自動更新が含まれており、サービスのサポート性と回復性の修正と改善、新機能も含まれます。
ほぼダウンタイムなしでポッドおよびゲートウェイ アプライアンスの更新を完了するために、システムはエンドユーザー セッションの数を使用します。アクティブなセッションで環境に接続しているユーザーの数が少ない場合、システムはセッション数を使用して更新を完了する最適なタイミングを決定します。
既存のポッドを新しいマニフェストに更新するメンテナンス アクティビティは、クラウド プレーンからシステムによって開始され、システムによって決定された日時に実行されます。
このようなシステム メンテナンス アクティビティを特定の時間と曜日に開始することを希望する場合は、コンソールを使用して、各ポッドの優先メンテナンス ウィンドウを指定します。
コンソールで優先メンテナンス ウィンドウが指定されていないポッドは、VMware がいつでも都合の良い時にそのポッドのメンテナンスをスケジューリングできると解釈されます。
たとえば、ポッドとそのゲートウェイ構成に使用されるサブスクリプションに関連付けられている Horizon Cloud サービス プリンシパルがカスタム ロール（非定型）を使用している場合、カスタム ロールにこれらの 2 つの権限が含まれていることを確認してください。拡張されたアップグレード API コードは、これらの権限に依存してマーケットプレイスからオファー リストを取得し、VMware オファーを取得します。カスタム ロールにこれらの 2 つの権限がまだ含まれていない場合は、ポッドとゲートウェイのアップグレード プロセスが実行される前に、それらをカスタム ロールに追加してください。
Microsoft.MarketplaceOrdering/offertypes/publishers/offers/plans/agreements/read Microsoft.MarketplaceOrdering/offertypes/publishers/offers/plans/agreements/write
デプロイされたポッドで使用されるソフトウェア コンポーネントが新しいバージョンに更新されると、ポッドのマニフェスト番号は 2632.0 などのより高いバージョン番号に増加します。ポッドのサービス性とサポート業務で重要と考えられる改善点がある場合、VMware は 2632.1 などのポイント バージョンの新しいマニフェストを作成できます。コンソールの [キャパシティ] ページにポッドのマニフェストが表示されます。
3328 より前のマニフェストからのポッドの更新に関する重要な情報
2022 年 2 月以降、ポッド マネージャ仮想マシンの NIC は、Unified Access Gateway 仮想マシンの NIC と同じインフラストラクチャ設計パターンに従います。
その時点で開始された新しいポッドのデプロイ、およびマニフェスト 3328 より前のマニフェストからのポッドの更新では、デプロイヤは、ポッドの実行とその後の更新をサポートするために必要なすべてのネットワークをインスタンス化します。ポッドのリソース グループに次の 8 つの NIC が追加されます。
- ポッドの管理サブネットから 4 つの IP アドレスを予約する 4 つの NIC。
- ポッドのプライマリ仮想マシン サブネット（旧称テナント サブネット）から 4 つの IP アドレスを予約する 4 つの NIC。
これらの 8 つのポッド NIC は持続し、割り当てられた IP アドレスをポッドの存続期間中予約し続けます。
この設計では、より高速で回復力の高いポッドの更新がサポートされます。この設計より前は、ポッドの更新では、Green ポッドのビルドアウトの一部として新しい NIC を作成し、更新時にポッドのサブネットからそれらの NIC の IP アドレスを取得する必要がありました。その設計では、Azure でタイムアウトが発生し、更新プロセスが中断される可能性があります。
デプロイヤが必要なすべてのネットワークを前もってインスタンス化するこの設計では、管理および仮想マシン（テナント）サブネットの NIC とその IP アドレスが保持され、後続のポッドの更新で使用されます。この設計は、Unified Access Gateway インスタンスで使用されるパターンに従います。
ポッドのリソース グループに 8 つの NIC がまだ存在せず、ポッドがマニフェスト 3328 以降に更新されるようにスケジュール設定されている場合は、次のアクションを実行する必要があります。
- そのポッドを更新する前に、ポッドの管理サブネットの IP アドレスとプライマリ仮想マシン（テナント）サブネットの IP アドレスが、 Horizon Cloud on Microsoft Azure が作成および構成するアイテムによってのみ取得されることを確認してください。
-
- 管理サブネット - ポッド デプロイヤが作成および構成した、Horizon Cloud on Microsoft Azure デプロイの特定の NIC のみが、ポッドの管理サブネットからの IP アドレスを使用する必要があります。これらの NIC は、ポッド マネージャの NIC と、ポッドの Unified Access Gateway インスタンスの NIC です。ポッドの管理サブネットには、ポッドがデプロイされていないリソースまたはアイテムを接続したり、ポッドから IP アドレスを取得したりすることはできません。
- テナント サブネット - ポッド デプロイヤが作成および構成した、Horizon Cloud on Microsoft Azure デプロイの特定の NIC およびロード バランサのみが、ポッドのテナント サブネットからの IP アドレスを使用する必要があります。ポッドのテナント サブネットには、デプロイ以外のリソースまたはアイテムを接続したり、ポッドから IP アドレスを取得したりすることはできません。
『デプロイ ガイド』には、ポッドで使用されるサブネットには、ポッド デプロイのリソース以外に追加のリソースを接続する必要はないと正確に記載されています。手動でリソースを作成し、ポッドの管理またはテナント サブネットからそのような追加のリソースに IP アドレスを割り当てた場合は、ポッドの更新を実行する前にそれらのリソースからそれらの IP アドレスを削除する必要があります。そうしないと、ポッドの更新に失敗し、VMware のサポートが必要になります。
- ポッドを更新した後、更新前に設定したファイアウォール ルールに、ポッドのリソース グループ内のデプロイヤが作成した NIC によって予約されたすべての IP アドレスを追加します。
- ポッド マネージャ仮想マシンの NIC の IP アドレスからのトラフィックを制御する既存のファイアウォール ルールがある場合があります。ポッドの更新後も更新前と同様にトラフィック通信が機能するようにするには、ポッドのリソース グループ内の NIC によって予約された 8 つの IP アドレスすべてが、更新後にファイアウォール ルールに反映されるようにする必要があります。
ポッドのメンテナンスに関する情報
デプロイされた Horizon Cloud ポッドを構成する VMware ソフトウェア コンポーネントのメンテナンスは、そのポッドによってプロビジョニングされた仮想デスクトップおよびアプリケーションの正常性と安定性を維持するために必要な操作です。VMware Horizon Cloud Service - 追加のサービスの詳細 (KB87894) で説明したように、VMware には、ポッドに常駐し、制御プレーンからそのポッドにダウンロードされるソフトウェア コンポーネントを管理する責任があります。このナレッジベースの記事に添付されている『VMware Horizon Cloud Service - 追加のサービスの詳細』PDF には、次の情報が記載されています。
- ポッドにダウンロードされるソフトウェア コンポーネントの正常性を維持するための変更管理手順に関する VMware の役割と責任。メンテナンス アクティビティには、ポッドのソフトウェア コンポーネントの更新が含まれます。
- スケジュールされたメンテナンスや緊急メンテナンスが必要な場合の VMware との連携を含めた変更管理手順に関するユーザーの役割と責任。
『VMware Horizon Cloud Service - 追加のサービスの詳細』ドキュメントには、スケジュール設定されたメンテナンス、メンテナンス期間、および緊急メンテナンスの定義が含まれます。これらの詳細については、該当ドキュメントを参照してください。このドキュメント ページの内容と『VMware Horizon Cloud Service - 追加のサービスの詳細』ドキュメントの内容に相違がある場合は、『VMware Horizon Cloud Service - 追加のサービスの詳細』ドキュメントが優先されます。
ポッドの優先メンテナンス ウィンドウの指定
ポッドのメンテナンス アクティビティを特定の時間と曜日に開始したい場合は、コンソールを使用して、そのポッドの優先メンテナンス ウィンドウと呼ばれる時間を指定します。[キャパシティ] ページで、ポッドの詳細ページの [メンテナンス] タブに移動します。[優先メンテナンス時間] というラベルを探し、画面上のコントロールに従って、その日の曜日名と時間 (UTC) を選択します。表示されるシステムで事前定義されたデフォルト値からのみ選択できます。
コンソールの各ポッドの詳細ページで、各ポッドの優先メンテナンス時間を個別に指定します。
システムは、コンソールで指定した曜日と時刻を読み取り、そのデータをスケジューリング アルゴリズムに組み込みます。クラウド プレーンで新しいポッド マニフェストがデフォルトとして設定されている場合、システムのスケジューラは、ポッド フリートの各ポッドで更新が発生する可能性があると判断した実際の更新日時を計算します。システムは、そのポッドの [メンテナンス] タブで指定された優先メンテナンス開始時間に対応できるように最善を尽くしますが、特定の更新操作でこの優先メンテナンス開始時間に対応できる保証はありません。
本書の作成時点で、システムのスケジューラは、メンテナンス アクティビティの期間として 4 時間を指定します。一般的なポッドの更新にかかる時間は、この割り当てられた期間よりも短い時間になります。
メンテナンス アラートと通知
システムは、特定のポッドについて特定のメンテナンスが実行されるように指定した特定のカレンダー日時をシステムがスケジュール設定したときに、テナント環境の管理者にアラートと通知を送信します。これらのアラートと通知には、次のものが含まれます。
- コンソール内
-
- コンソールの上部に表示されるパーシステント バナー。バナーの時間は、コンソールを表示しているときの、ブラウザのタイムゾーンに対するローカルなメンテナンス時間です。次のスクリーンショットは、2020 年 7 月 7 日の米国東部時間午後 4 時にポッドの更新がスケジューリングされている例です。[表示] ボタンを使用し、クリックしてポッドの詳細ページに移動し、ポッドの [メンテナンス] タブでスケジューリングされたメンテナンスの詳細を確認します。
- ポッドの [監査ログ] タブおよびコンソールの で、監査ログにポッドのアップグレードが VMware Operations によってスケジューリングされていることが示されます。監査ログ行には、ポッドの UUID が含まれます。
- ポッドの [メンテナンス] タブで、[スケジューリングされたメンテナンス] セクションに、スケジューリングされたメンテナンスに関する情報が表示されます。
- コンソールの上部に表示されるパーシステント バナー。バナーの時間は、コンソールを表示しているときの、ブラウザのタイムゾーンに対するローカルなメンテナンス時間です。次のスクリーンショットは、2020 年 7 月 7 日の米国東部時間午後 4 時にポッドの更新がスケジューリングされている例です。[表示] ボタンを使用し、クリックしてポッドの詳細ページに移動し、ポッドの [メンテナンス] タブでスケジューリングされたメンテナンスの詳細を確認します。
- E メール
- システムは、ポッドのメンテナンスに関する E メールをテナント環境の管理者（コンソールの 設定で指定された管理者）に送信します。E メールには、システムが定期メンテナンスの特定のカレンダー日時を設定したときの E メールが含まれます。このような E メールの例には、スケジューリングされた日時より前の日と週の定期的なリマインダ、メンテナンス アクティビティの開始時、および完了時が含まれます。
ポッドのメンテナンスを実行する前のシステム事前チェック
ポッドにポッド更新エラーがあることを通知する E メールを受信した場合、またはコンソールがポッドのポッド更新エラーを報告した場合は、状況を修正するためのアクションを実行する必要があります。この問題が発生した場合は、コンソールの画面上のガイダンスまたは E メールの指示に従ってください。このようなエラーの通常の解決策として、一般に、ポッドのサブスクリプション内の Microsoft Azure ポータルで手順を実行する必要があります。一般的なポッドの更新エラーに対する修正の詳細については、Horizon Cloud ポッド：一般的な事前チェックの失敗の対処法を参照してください。
これらの事前チェックの目的は何ですか。ポッドの更新のメンテナンス アクティビティは、ポッドの Microsoft Azure サブスクリプションおよびリソース グループで実行されます。システムが特定のポッドに対する特定の更新について、特定のカレンダー日時をスケジューリングする少し前に、システムは事前チェック操作を実行して、ポッドの更新の成功を妨げる条件が存在するかどうかを判断します。これらの事前チェックの 1 つの例として、システムは、Microsoft Azure サブスクリプションに更新の要件を満たすのに十分な適切な仮想マシン シリーズの vCore があるかどうかを確認します。事前チェックの 1 つが失敗し、条件を修正するためにアクションが必要な場合は、次の処理が発生します。
- この事実についてのアラートと、エラーの修正に必要なアクションの詳細を記載した通知 E メールが送信されます。
- コンソールには、そのポッドの事前チェック エラーを修正するために必要なアクションが視覚的アラートで表示されます。
ポッドの更新：概要
メンテナンス アクティビティがポッドの新しいマニフェスト バージョンへの更新である場合、システムはポッドの現在のインフラストラクチャ コンポーネントを適切により高いソフトウェア マニフェスト レベルに移動します。主要なインフラストラクチャ コンポーネントは、ポッド マネージャ仮想マシンと、ポッド用に構成されているすべての Unified Access Gateway 仮想マシンです。たとえば、ポッドのアップデートにはポッド管理ソフトウェア、Unified Access Gateway ソフトウェア、またはそれらの両方のアップデートを含めることができます。
このポッドの更新プロセスは、Blue-Green デプロイとして知られるソフトウェア業界の手法を模したものです。既存の更新対象のポッド コンポーネントは、Blue コンポーネントと見なされます。
ほとんどの場合、ポッドの更新は業界の Blue-Green パターンに従っていますが、標準の Blue-Green 更新とはいくつかの小さな違いがあります。ポッドの更新では、Green のビルドアウト内の Blue のリソースを 100% 複製するわけではありません。Unified Access Gateway の NIC など既存の Blue の一部は、新しい Green のビルドアウトで再利用されます。もう 1 つの違いとして、ポッドの更新プロセスでは、既存のインスタンスのほかに新しいインスタンスが作成されると、新しいインスタンスがパワーオンされ、ポッドが新しいインスタンスへの移行を完了するまで実行を続けます。また、システムがポッドを Green のビルドアウトに移行し、ポッドが新しいマニフェスト バージョンで正常に実行されていることを検証した後、古い Blue の仮想マシンがリソース グループから削除されます。（通常、正規の Blue-Green の更新では、Green に切り替えた後も古い Blue のアーティファクトが保持され、古いアーティファクトはアイドル状態に保たれます。）
- 既存の更新されるポッド コンポーネント（ポッド マネージャ仮想マシンや仮想マシン Unified Access Gateway など）は、Blue コンポーネントと見なされます。
- サービスは、Microsoft Azure サブスクリプション内のポッドに必要な Green のコンポーネントのセット（新しい Green のポッド マネージャ仮想マシン、Unified Access Gateway 仮想マシン、ゲートウェイ コネクタ仮想マシン）を自動的に構築します（外部ゲートウェイが専用の VNet にデプロイされている場合）。
- Green のビルドアウトの新しく作成されたコンポーネントは、Blue のコンポーネントと一緒に同じリソース グループ内に作成されます。
- Green のビルドアウトを作成するプロセスでは、ダウンタイムやデータ損失は発生しません。また、パラレル仮想マシンはポッドの操作に影響しません。
- Green のセットはパラレル環境であり、Blue から Green に切り替わる、スケジューリングされたメンテナンス アクティビティの準備ができています。システムがポッドでメンテナンス アクティビティをスケジューリングする方法については、前のセクションで説明します。
- これらの Green の仮想マシンが開始され、スケジューリングされたメンテナンス アクティビティ（Blue から Green に移行するメンテナンス アクティビティ）が完了するまで実行され続けます。
- Green のビルドアウトに移行するためのスケジューリングされたメンテナンス アクティビティが完了し、ポッドが新しいインスタンスで正常に実行されると、システムはポッドのリソース グループから Blue の仮想マシンを削除します。Unified Access Gateway インスタンスの NIC など、一部のリソースは次回のポッドの更新に必要な構成の値を保持するために残ります。
メンテナンス アクティビティの順序
この手順では、Green のビルドアウトへの移行について説明します。ポッドのアップデートでは、スイッチが Blue から Green に切り替わります。
- システムは、コンソールで指定したポッドの優先メンテナンス ウィンドウをチェックし、その情報をスケジューラのアルゴリズムで使用して、ポッドのメンテナンス アクティビティの実際のカレンダー日時をスケジューリングします。
- システムのスケジューラは、メンテナンスが実行される実際のカレンダー日時を選択します。前のセクションで説明したように、コンソールにはスケジューリングされた日時が視覚的に表示され、テナントの管理者に E メールが送信されます。
-
重要： スケジューリングされたメンテナンスを実行する前に、次の作業を行います。
- ポッドのイメージ仮想マシン、ファーム仮想マシン、および VDI デスクトップ仮想マシンに、ポッドで使用できる最新のエージェントがすべて含まれていることを確認します。コンソールで青いドットが表示されている場合は、ポッドを更新する前に、コンソールからすべての青いドットを消します。詳細については、Horizon Cloud ポッドの更新：エージェントの互換性とサポートを継続するための手順
- ポッドの仮想マシン (VM) で設定した Microsoft Azure の管理ロックがあればすべて削除します。名前に vmw-hcs-
podIDのような部分（podIDはポッドの ID 値）を持つすべての仮想マシンはポッドに属します。Microsoft Azure では、Microsoft Azure ポータルを使用してリソースが変更されないようにロックすることができます。このような管理ロックは、リソース グループ全体または個々のリソースに適用できます。ユーザーまたは組織がポッドの仮想マシンに管理ロックを適用した場合、更新を実行する前にそれらのロックを削除する必要があります。そうしないと、更新プロセスは正常に完了しません。ポッドの ID 値は、[キャパシティ] ページからアクセスできるポッドの詳細ページで確認できます。
組織のニーズに応じて、スケジュールリングされたメンテナンス時間より前であればいつでも VMware のサポートに連絡して、別のスケジューリングされたメンテナンス日をリクエストできます。
重要： コンソールに表示されるスケジューリングされた時間は、ブラウザのタイム ゾーンに対してローカルです。 - スケジュール設定されたメンテナンス時間に、サービスは更新アクティビティを開始します。外部と内部の両方の Unified Access Gateway 構成を持つポッドの場合、完全なプロセスには通常、開始から終了まで 20 ～ 30 分かかります。
注： プロセスが完了するまでの 20 ～ 30 分間は、コンソールによって、更新中のポッドで管理タスクを実行できなくなります。たとえば、ポッド マネージャ アプライアンスがクラウド プレーンに更新が完了したことを通知するまで、ポッドの詳細ページの [編集] アクションをクリックしてそのポッドの特性を変更することができません。
- Unified Access Gateway アプライアンスでのエンドユーザー セッションと更新アクティビティについて
-
エンドユーザー セッションのダウンタイムをゼロに近くするため、システムは、全体的なメンテナンス アクティビティ時間内に、アプライアンス上のエンドユーザー セッションの数を使用して、これらのアプライアンスの更新を完了するための最適なタイミングを決定します。
完了時間は、アクティブなセッションで環境に接続されているユーザーの数が少ない場合に発生するように最適化されています。
このゼロに近い時間枠では、アクティブなセッションを持つエンド ーザーはこれらのセッションが切断されます。数分後には、そのユーザーは再接続できるようになります。
ファームと VDI デスクトップ割り当てのタイムアウト処理に [直ちに実行] オプションを設定したシナリオを除き、データは失われません。そのシナリオでは、タイムアウト処理に [直ちに実行] オプションを使用したアクティブなセッションを持つユーザーはすぐに切断され、その設定に従ってそれらのセッションもすぐにログオフされます。このような状況では、進行中のユーザーの作業はすべて失われます。このシナリオで処理中のエンド ユーザーのデータが失われるのを回避するには、メンテナンス アクティビティを開始する前に、ファームおよび VDI デスクトップ割り当ての [切断されたセッションのログオフ] の設定を、ユーザーが作業を保存する時間を確保できる値に変更します。更新が完了したら、設定を元の値に戻すことができます。
また、ゼロに近い時間枠内で、ポッドから仮想デスクトップまたはリモート アプリケーションへのセッションをまだ接続していないエンド ユーザーが、接続を試みると、プロセスが完了するまで接続できなくなります。
- メンテナンス アクティビティが完了すると、システムは、Green のビルドアウトで再利用されない Blue コンポーネント（たとえばポッド マネージャ仮想マシンや Unified Access Gateway 仮想マシン）など、不要になったコンポーネントを削除します。ポッド マネージャ インスタンスや Unified Access Gateway インスタンスの特定の NIC など、一部のアーティファクトは今後のメンテナンスに必要な構成の値を保持するために残ります。
メンテナンス アクティビティの完了後
メンテナンス アクティビティが完了したら、ポッド上で管理タスクを実行できます。ポッドで現在実行されているソフトウェアのバージョンを表示するには、を選択して、サマリ ページを表示するポッドをクリックします。ページに現在実行されているソフトウェア バージョンが表示されます。
- ポッドの更新後、既存のすべてのイメージ、ファーム、および VDI 割り当てのエージェントが利用可能な最新バージョンに更新されていることを確認します。これらの仮想マシンにインストールされているエージェントが更新されない場合、ポッドはサポートされていない構成になります。メンテナンス プロセスでは、それらのインストールされているエージェントは自動的に更新されません。コンソールにイメージまたは割り当てに対して青いドットが表示されている場合は、エージェントを更新する必要があります。Horizon Cloud ポッドの更新：エージェントの互換性とサポートを継続するための手順。
- この更新がマニフェスト 3328 より前のマニフェストからのものである場合は、ポッドを更新した後に、ポッドのリソース グループ内にあるデプロイヤが作成した NIC のすべての IP アドレスをファイアウォール ルールに追加してください。ポッド マネージャ仮想マシンの NIC の IP アドレスからのトラフィックを制御する既存のファイアウォール ルールがある場合があります。このポッドの更新後、およびその後のポッドの更新後も更新前と同様にトラフィック通信が機能するようにするには、ポッドのリソース グループ内の NIC によって予約された 8 つの IP アドレスすべてが、更新後にファイアウォール ルールに反映されるようにする必要があります。
- 構成済みの 2 要素認証サーバが同じ VNet にデプロイされている場合は、メンテナンス アクティビティへの移行後に、新しい内部 Unified Access Gateway 仮想マシンの新しいプライベート IP アドレスを受け入れるように 2 要素認証サーバ側の設定を更新する必要があります。これは、ポッドでの最初の更新に対する 1 回限りの要件であり、そのポッドの将来の更新で繰り返す必要はありません。必要なゲートウェイ情報を使用して 2 要素認証システムを更新するを参照してください。
- 2019 年 9 月の四半期サービス リリース以降、ポッド アーキテクチャは、高可用性 (HA) を保有する機能をサポートするように更新されています。高可用性機能が有効になっていなくても、HA 対応の新しいアーキテクチャにはポッドのマネージャ仮想マシンの前に Microsoft Azure ロード バランサが含まれています。ポッドをマニフェスト 1600 に更新した後、ポッドが直接接続用に構成されていた場合は、更新されたポッドの詳細ページに新たに表示されるポッド マネージャの Azure ロード バランサの IP アドレスをポイントするように、DNS 設定を再マッピングする必要があります。DNS マッピングを更新するまでは、これらの直接ユーザー接続は引き続き機能しますが、アクティブなポッド マネージャ仮想マシンがダウンした場合に、これらの接続では HA 対応ポッドが提供するように設計されている高可用性フェイルオーバーは行われません。このユースケースでは、コネクタがポッド マネージャ仮想マシンへの接続を信頼できるように、Workspace ONE Access コネクタ アプライアンスを Microsoft Azure の Horizon Cloud ポッドと統合する場合には、ポッド マネージャ仮想マシンで SSL 証明書を直接構成します。の説明に従って、ポッドの詳細ページに表示される、[ポッド マネージャのロード バランサの IP アドレス] フィールドの IP アドレスに FQDN をマッピングします。ポッド マニフェスト 1600 以前は、その IP アドレスはテナント サブネット上のポッドのマネージャ仮想マシンの NIC に割り当てられたものでした。ポッド マニフェスト 1600 以降では、マッピングするポッドの IP アドレスは、ポッドのマネージャ仮想マシンに使用される Microsoft Azure ロード バランサのプライベート IP アドレスになります。このリリースのマニフェスト バージョンに更新された既存のポッドの場合、マニフェスト 1493.1 以前のポッドのテナント アプライアンスの IP アドレスをポイントするように DNS 名を構成した場合は、更新したポッドの詳細ページの [ポッド マネージャのロード バランサの IP アドレス] ラベルに表示される IP アドレスをポイントするように DNS 設定を再マッピングする必要があります。
- 2474.x より前のマニフェストでは、システムは登録済みの Active Directory サーバのクロック スキューを確認しませんでした。2474.x では、クロック スキューのチェックが導入されました。登録済みの Active Directory サーバに時刻同期の問題がある場合（
clockSkew > 4 minutes）、ポッドが 2474.x 以上にアップグレードされると、そのポッドでこのシステム検証が開始されます。その結果、クロック スキューの問題を解決するまで、Active Directory サーバの検出が失敗します。検出に失敗すると、そのポッドへのエンド ユーザー デスクトップ接続要求に影響が及ぶことがあります。
