パッチをどの順序で、どのくらいの範囲に配信するかを設計します。全台に一斉配信すると、問題のある更新が全社に影響します。段階的に広げる仕組みを作ってください。
承認フローの考え方
更新の種類ごとに、承認の方針を変えるのが実務的です。
| 種類 | 推奨する方針 | 理由 |
|---|---|---|
| セキュリティー更新 | 自動承認 | 適用の遅れがリスクに直結する |
| 重要な更新 | 自動承認または短期の検証 | 安定性に関わる |
| 機能更新 | 手動承認 | 業務への影響が大きい |
| ドライバー更新 | 手動承認 | 特定機種で問題が出やすい |
全てを手動承認にすると、承認作業が滞って適用されないまま放置されます。全てを自動承認にすると、問題のある更新が全台に配信されます。種類による切り分けが現実解です。
承認設定の構成
Policyの承認設定は3つの区分に分かれます。
Security update approvals、General approvals、Advanced approvalsのそれぞれで承認の方針を指定するSecurity update approvals
セキュリティー更新を深刻度ごとに扱います。Critical、Important、Moderate、Lowの4段階です。
General approvals
更新の種類ごとに扱います。Critical updates、Regular updates、Update rollups、Service packs、Feature packs、Definition packsが並びます。
さらにIMPORTANT PATCHESとOPTIONAL PATCHESで列が分かれており、重要度によって別の方針を設定できます。
Advanced approvals
DriversとFeature updatesを扱います。初期状態ではDisabledです。
ドライバーの更新は特定機種で問題が出やすく、機能更新は業務への影響が大きいため、既定で無効になっています。有効にする場合は検証を前提にしてください。
承認の方法を選ぶ
各項目に指定できるのは次の3つです。
| 設定 | 挙動 |
|---|---|
Approve after N days | 公開からN日後に自動で承認する |
Manual | 手動で承認するまで配信しない |
Rejected | 配信しない |
Approve after N daysが実務上最も重要な設定です。日数を指定することで、公開直後の不具合が判明する期間を待ってから配信できます。
| 対象 | 推奨する設定 |
|---|---|
セキュリティー更新のCritical | Approve after 0〜3 days |
セキュリティー更新のImportant | Approve after 3〜7 days |
Regular updates | Approve after 7 days |
Feature packs | Manual |
Drivers | RejectedまたはManual |
深刻度が高いものほど日数を短く、業務への影響が大きいものほど手動にする、という設計になります。
手動での承認と却下
個別の更新を承認または却下することもできます。
却下を使うのは、問題が判明した更新を配信対象から外す場合です。特定の更新で不具合が報告されたとき、却下すれば以降の配信を止められます。
【注意】 却下は「配信しない」だけで、既に適用済みのデバイスからは削除されません。適用後に問題が判明した場合は、アンインストールの手順を別途実施する必要があります。
リング展開の設計
段階的に配信範囲を広げる方法です。3段階に分けるのが基本です。
検証グループ
最初に配信する少数のデバイスです。情報システム部門の端末や、検証用に用意した端末を割り当てます。
条件は次の通りです。
- 問題が起きても業務に影響しない
- 問題に気付ける人が使っている
- 業務で使う主要なソフトウェアが入っている
台数は5台から10台程度で十分です。
段階展開
検証グループで問題がなければ、次の範囲に広げます。全体の10%から20%程度を目安にします。
対象の選び方は、部署単位か拠点単位が管理しやすくなります。「情報システム部門と総務部」のように、範囲を明確にしてください。
全体展開
段階展開で数日間問題がなければ、残り全体に配信します。
| 段階 | 対象 | 待機期間 |
|---|---|---|
| 検証 | 5〜10台 | 2〜3日 |
| 段階 | 全体の10〜20% | 3〜5日 |
| 全体 | 残り全て | ― |
待機期間は、問題が表面化するまでの時間を確保するためです。適用直後は問題が出ず、数日使ってから発覚することがあります。
リング展開の実装
Approve after N daysの日数をPolicyごとに変えることで実現します。
| Policy | 対象 | Approve after |
|---|---|---|
Patch-Ring1-検証 | 検証グループ | 0日 |
Patch-Ring2-段階 | 段階展開の対象 | 3日 |
Patch-Ring3-全体 | 残り全体 | 7日 |
同じ更新でも、検証グループには即日、全体には7日後に配信されます。Policyを分けたうえでDevice Roleを対応させてください。設計の考え方はPolicyとは：設計の考え方を参照してください。
この方式の利点は、承認の作業自体が不要になることです。手動承認では、承認を忘れた期間だけ適用が止まります。日数を指定しておけば、担当者が不在でも計画どおりに配信が進みます。
Staggerによる負荷分散
同じタイミングで多数のデバイスが更新をダウンロードすると、回線を圧迫します。Staggerはこれを防ぐ設定です。
Stagger overで指定した時間幅の中に、実行タイミングを分散させるScan scheduleとUpdate scheduleの両方にStagger overがあります。ここで時間幅を指定すると、対象デバイスの実行タイミングがその範囲内に分散されます。
設定の目安は次の通りです。
| 環境 | Staggerの設定 |
|---|---|
| 帯域に余裕がある本社 | 30分から1時間 |
| 回線が細い拠点 | 2時間から4時間 |
| モバイル回線の端末 | Skip on metered connectionsを併用 |
Pre-stage updates before scheduled startと組み合わせると、さらに効果があります。適用の時刻とは別に、事前にダウンロードだけを済ませておけます。
【運用のポイント】 拠点の回線が細い場合、Staggerだけでは足りないことがあります。その場合は拠点ごとにPolicyを分け、適用の時間帯自体をずらしてください。Location単位でPolicyを上書きする方法は親ポリシーと継承・上書きを参照してください。
問題が起きたパッチへの対応
適用後に問題が判明した場合の手順です。
- その更新を却下し、以降の配信を止める
- 適用済みのデバイスを特定する
- 影響の有無を確認する
- 必要ならアンインストールを実施する
- 対応内容を記録する
2番目の特定は、デバイス一覧のフィルターで行えます。リング展開をしていれば、影響範囲は検証グループか段階展開の範囲にとどまります。これがリング展開を行う最大の理由です。