Windows クライアント更新プログラムのサービス戦略を準備する
ユーザー向けの情報を探している場合、 「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 ユーザーと対象グループに機能更新プログラムをデプロイします。 できるだけ早くフィードバックを求めていることを明確に伝え、ユーザーがフィードバックを送信する方法を正確に明記してください。 問題が発生した場合は、修復計画を立ててください。
- 広範に展開する。 最後に、デプロイ リングを使用した大規模なデプロイに焦点を当てます。 選択した更新管理製品で、コンピューターのグループを対象とした展開リングを構築します。 できるだけリスクを抑えるには、展開リングを構築する際に、個々の部門を複数のリングに分割します。 このようにすると、問題が発生した場合は、重要なビジネスの継続を妨げる必要はありません。 この方法を使用すると、特定の部門で更新されたユーザーが増えるにつれて、各デプロイ リングによってリスクが軽減されます。