コンサルタントは、マイクロソフトのアップデートメンテナンスの不備により、この問題が貴重なパッチリソースを浪費していると指摘しています。
「予定通りに進みませんでした。変更を元に戻しています。」これが、EFIシステムパーティション（ESP）の空き容量不足が原因でマイクロソフトの5月セキュリティアップデートのインストールに失敗したWindows 11ユーザーが得られるすべての手がかりです。このため、システムは含まれていた数十のパッチによる保護が失われます。
この問題は、ESPで利用可能な空き容量が限定されている（通常10MB以下）デバイスに影響します。「影響を受けたデバイスでは、インストールが初期段階を進む可能性がありますが、再起動フェーズ中の約35～36％の完了時点で失敗する可能性があります」と、マイクロソフトはアドバイザリーで述べています。Windowsレジストリ設定を変更してアップデートを強制するか、変更をロールバックして将来のアップデートで問題を修正するのを待つことを推奨しています。
コンサルタントは、予期しない露出と失敗が運命付けられたパッチがインストール失敗に至るまでの時間を考えると、潜在的に深刻な問題だと述べています。
これはITリーダーを夜眠れなくさせるような失敗の一種だと述べたのは、FormerGovの執行委員会長を務めるサイバーセキュリティコンサルタントBrian Levine氏です。「セキュリティアップデートが独自のブートパーティションの状態を誤判定するためにインストールできない場合、問題はストレージだけではありません。本当の問題はアップデートプロセスへの信頼です」と彼は述べています。「これは技術的な問題に見せかけた基本的なメンテナンスの失敗です。EFIシステムパーティション上の利用可能な容量を確実に検出できないアップデートは、小さなミスではありません。これは、成熟したプラットフォームでも依然として依存関係認識と飛行前検証に苦労していることの警告です。」
GartnerのシニアディレクターアナリストEric Grenier氏は、アップデートが進められるようにディスクパーティションのサイズを1.5GBに増やすことを推奨しました。「これはエンドユーザーの利用可能な容量という観点でビジネスニーズを損なうべきではありません」と彼は述べ、これはWindows回復環境の更新も可能にすると付け加えました。彼は、マイクロソフト独自の推奨事項が問題につながる可能性があると警告しました。「組織が修正されたレジストリの修正を使用したいと考えている場合、レジストリを事前にバックアップするだけでなく、環境の残りに展開する前にいくつかのパイロットデバイスでテストすることをお勧めします。その場合でも、何も壊れないようにするために緩いフェーズドロールアウトを行います」と彼は述べています。「本番環境でのこのようなタイプの修正は非常に慎重に行われるべきです。正しく行われない場合、修正はキーボードでの作業が必要になるからです。」
コーディング生産性ツールベンダーKodeziのCEOIshraq Khan氏は、ITチームとマイクロソフト両方に責任があると述べています。
「ほとんどのITチームは、Windows Updateが事前チェックに合格してインストールが開始された場合、マイクロソフトはすでに再起動段階の失敗を回避するのに十分にシステムの状態を検証していると合理的に想定しています。ESP空間がアップデートの成功に重要な場合、更新プログラムは以前にその状態を検出し、明確な修復メッセージでブロックすべきでした」とKhan氏は述べています。「したがって、IT環境は時間をかけてパーティションの圧力に寄与する可能性がありますが、マイクロソフトは依然としてアップデートの進行を許可したオーケストレーション検証ロジックを所有しています。」
Khan氏は、これは非常に高額なエンタープライズIT頭痛になる可能性があると付け加えています。「再起動中の失敗はインストール開始前のアップデートのブロックよりもはるかに破壊的であるため、これはエンタープライズITの設計上の問題です。ソフトウェア保守の観点からは、これはエンタープライズスケールで高額になる正確なエッジケースです。マシンのサブセットの小さなパーティション制約は、ヘルプデスクチケット、ロールバックサイクル、パッチの遅延、セキュリティ露出に変わる可能性があります。」
コンサルティング企業Acceligenceの最高執行責任者David Neumann氏は、これが実質的なIT頭痛だと同意しています。
「アップデートは初期段階を通過しているように見えますが、その後再起動フェーズ中に失敗します。つまり、ITはエンドポイントが既にメンテナンスウィンドウ時間を消費してロールバックするまで発見されない可能性があります。企業では、これは1回限りのヘルプデスク問題ではなく、フリート衛生の問題になります」と彼は述べています。「影響を受けたエンドポイントは、ITがより早く説明されるべき失敗を診断するために時間を消費している間、パッチが適用されないままになる可能性があります。より大きな教訓は、ブート、回復、ファームウェア隣接パーティションがパッチ管理衛生の一部であるということです。成熟したITチームは、ESP サイズと空き容量チェックをエンドポイント健康レポートに追加し、新しいデプロイメントが適切なESP容量を持つようにゴールドイメージを更新し、ブレークフィックススクリプティングではなくライフサイクルエンジニアリングとしてブートパーティションのクリーンアップまたはサイズ変更を扱うべきです。」
マイクロソフトはコメント要求に応応じませんでした。
