Windows クライアント更新プログラムのサービス戦略を準備する
適用対象
- Windows 10
- Windows 11
ユーザー向けの情報を探している場合、 「Windows Update: FAQ」をご覧ください。
このプロセスの例を次に示します。
- テスト デバイスを構成する。 Windows Insider Program でテスト デバイスを構成して、Insider が機能更新プログラムを一般提供チャネルで利用できるようになる前にテストできるようにします。 通常、この母集団は、IT スタッフメンバーが Windows のプレリリース ビルドを評価するために使用するいくつかのテスト デバイスです。 Microsoft によって追加される機能を関心のあるユーザーが確認できるように、ほぼ毎週、現在の開発ビルドが Microsoft から Windows Insider メンバーに提供されます。 Windows Insider Program for Business に登録する方法の詳細については、Windows Insider のセクションを参照してください。
- 除外されたデバイスを特定します。 一部の組織では、工場や医療機器を制御するデバイスや ATM を実行するデバイスなどの特殊な目的のデバイスでは、一般提供チャネルよりも厳密で頻度の低い機能更新サイクルが必要です。 これらのデバイスの場合は、Enterprise LTSC エディションをインストールして、最大 10 年間機能の更新を回避します。 これらのデバイスを特定し、段階的な展開とサービス サイクルから分離して、管理者の混乱を取り除き、デバイスが正しく処理されるようにします。
- テスト希望者を募る。 展開をテストする目的は、フィードバックを得ることです。 パイロット ユーザーを集める有効な方法の 1 つとして、テスト希望者を募ることができます。 その場合は、機能を試すだけではなくフィードバックが必要である点と、機能更新プログラムをすぐに受信すると問題が生じる場合もある点を明確に示します。 サービスとしての Windows では、いくつかの問題点が見込まれますが、実際に問題が発生した場合にはテスターからできるだけ早く報告を受ける必要があります。 パイロット グループのメンバーを検討する際には、できる限り多くのアプリとデバイスを評価できるように、広範なアプリケーションとデバイスを提供できるメンバーを含めるようにしてください。
- グループ ポリシーを更新します。 各機能更新プログラムには、新機能を管理するための新しいグループ ポリシーが含まれています。 グループ ポリシーを使用してデバイスを管理する場合、Active Directory ドメインのグループ ポリシー 管理は、.admx パッケージをダウンロードし、中央ストア (中央ストアを使用しない場合はドメイン コントローラーの SYSVOL フォルダー内の PolicyDefinitions ディレクトリ) にコピーする必要があります。 リモート サーバー管理ツールを使用して、Windows の最新リリースの新しいグループ ポリシーを管理できます。 ADMX ダウンロード パッケージは、各開発サイクルの最後に作成され、ダウンロード用に投稿されます。 特定の Windows ビルドの ADMX ダウンロード パッケージを見つけるには、「ADMX download for Windows build xxxx」を検索します。 グループ ポリシー管理の詳細については、「Windows でグループ ポリシー管理用テンプレートの中央ストアを作成および管理する方法」を参照してください。
- サービス ツールを選択する。 環境内で Windows 更新プログラムの管理に使用する製品を決定します。 現在、Windows Server Update Services (WSUS) または Microsoft Configuration Managerを使用して Windows 更新プログラムを管理している場合は、引き続きこれらの製品を使用してWindows 10またはWindows 11更新プログラムを管理できます。 または、Windows Update for Business を使うこともできます。 使用する製品のほか、更新プログラムの配布方法も検討する必要があります。 更新プログラムの配布を高速化するために、複数のピア ツー ピア オプションを使用できます。 ツールの比較については、「サービス ツール」をご覧ください。
- アプリケーションの優先順位を付ける。 まず、アプリケーション ポートフォリオを作成します。 この一覧には、組織でインストールされているすべてのアプリケーションと、組織でホスティングしているすべての Web ページを含めます。 次に、この一覧に優先順位を付けて、最もビジネスクリティカルなアプリを特定します。 新しいバージョンの Windows とのアプリケーションの互換性が高くなるという期待があるため、パイロット フェーズの前にテストする必要があるのは、最もビジネスクリティカルなアプリケーションだけです。他のすべてが後でテストできます。 アプリケーションとの互換性の問題の特定について詳しくは、Upgrade Analytics を使用した Windows アップグレードの管理のページをご覧ください。
Microsoft が機能更新プログラムをリリースするたびに、IT 部門は次の高度なプロセスを使用して、広範な展開が成功したことを確認する必要があります。
- ビジネス クリティカルなアプリの互換性を確認する。 前のセクションの「テスト デバイスの構成」の手順で特定した Windows Insider マシンで実行されている新しいWindows 10機能更新プログラムとの互換性について、最も重要なビジネス クリティカルなアプリケーションをテストします。 ほとんどのアプリケーションはパイロット フェーズでテストできるため、この検証プロセスに含めるアプリケーションの数は限定する必要があります。
- 対象を設定してフィードバックに対応する。 Microsoft では、アプリケーションとデバイスの互換性が高くなる見込みですが、アプリケーション ポートフォリオ内の残りのアプリケーションのアプリケーション互換性を確認するには、IT 部門とビジネス ユニットの両方にターゲット グループを配置することが依然として重要です。 最もビジネスクリティカルなアプリケーションのみが事前にテストされるため、このアクティビティは環境内のほとんどのアプリケーション互換性テストを表します。 必ずしも正式なプロセスではなく、特定のアプリケーションを使用してユーザー検証を行う必要があります。 そのため、次の手順では、前のセクションの「ボランティアを募集する」の手順で特定した一般提供チャネルで実行されている早期導入の IT ユーザーと対象グループに機能更新プログラムをデプロイします。 できるだけ早くフィードバックが必要であるということと、ユーザーからのフィードバック提出方法を必ず伝えてください。 問題が発生した場合は、修復計画を立ててください。
- 広範に展開する。 最後に、デプロイ リングを使用した大規模なデプロイに焦点を当てます。 選択した更新管理製品で、コンピューターのグループを対象とした展開リングを構築します。 できるだけリスクを抑えるには、展開リングを構築する際に、個々の部門を複数のリングに分割します。 これにより、問題が発生してもクリティカルな業務の停止を回避できます。 この方法を使用すると、特定の部門で更新されたユーザーが増えるにつれて、各デプロイ リングによってリスクが軽減されます。