次の方法で共有


カレンダーを使用して更新戦略を定義する

従来、組織はオペレーティング システムの更新プログラム (特に機能更新プログラム) の展開を、開始、中間、終了を持つ個別のプロジェクトとして扱っていました。 リリースは "ビルド" され (通常はイメージの形式で)、ユーザーとそのデバイスに配布されました。

現在、より多くの組織が展開を、波の中のorganization全体に展開する継続的な更新プロセスとして扱っています。 この方法では、更新プログラムがこのプロセスに接続され、実行中に異常、エラー、またはユーザーの影響を監視し、問題が発生した場合はプロセス全体を中断することなく対応します。 Microsoft では、このモデルをサポートするために、Windows のリリース サイクル、更新メカニズム、関連ツールを進化させてきました。 Windows ライフサイクルの詳細については、「 Windows ライフサイクルに関する FAQ」を参照してください。

使用可能なすべてのリリースをデプロイし、環境の一部に対して迅速な間隔を維持することをお勧めします。 また、多数のデバイスがあり、中断がほとんどまたはまったく必要ない可能性があることを認識しています。 ライフサイクルの間隔を使用すると、環境の一部をより速く移動できますが、大部分は移動速度を低下させることができます。

予定表のアプローチ

カレンダー アプローチは、年 2 回の間隔または年単位で実行できます。 会社の規模によっては、機能更新プログラムを年に 1 回よりも少なくインストールすると、バージョンがサポート対象外になると毎月のセキュリティ更新プログラムの受信が停止するため、デバイスがサービスを停止し、セキュリティ上の脅威に対して脆弱になるリスクがあります。

年次アプローチ

次に示すのは、カレンダー年に 1 回の Windows 機能更新プログラムを適用するスケジュールの例を示しています。これは、Microsoft Configuration ManagerとMicrosoft 365 Appsリリース サイクルに合わせて調整されています。

年次更新間隔を示す予定表。

この方法では、次の更新プログラムが Windows H2 機能更新プログラムに合わせてインストールされる前に、各機能更新プログラムから約 12 か月間の使用が提供されます。

次のいずれかの条件が適用される場合、この頻度が最も適している可能性があります。

  • Windows サービス プロセスで体験を始めたばかりです。 Windows サービスをサポートする新しいプロセスに慣れていない場合は、3 年から 5 年に 1 回発生するプロジェクトから機能更新プロセスへの移行が困難になる可能性があります。 このアプローチでは、新しいアプローチとツールを学習して、労力とコストを削減する時間を得られます。

  • 他の企業が Windows 機能更新プログラムを採用する際の成功を待ち、確認する必要があります。

  • 機能更新プログラムをすばやく使用し、ビジネスの優先順位が変化した場合に備えて Windows のサービスを維持しながら、機能更新プログラムをスキップできるようにする必要があります。