WSUSで一度「承認済み（Approved）」にしたドライバー更新が、端末交換や再セットアップ後のドメイン参加をきっかけに自動配布され、Surface Pro 7 などで不具合を再発させることがあります。本記事では、承認済みドライバーを「未承認（Not Approved）」へ戻す具体手順と、安全な運用のコツを解説します。
なぜ「過去に承認したドライバー」が新しい端末にも自動で入ってしまうのか
WSUS（Windows Server Update Services）は、クライアントがWSUSへスキャン（更新の検出）に来たタイミングで、「そのコンピューターグループに対して承認されている更新」を提示します。つまり、端末が故障して交換したとしても、交換後の端末が同じWSUS設定（GPOなど）で管理下に入れば、以前に承認したドライバー更新が“また適用対象”として選ばれるのは自然な挙動です。
特にSurfaceシリーズは、ドライバーだけでなくファームウェア（UEFI/各種コントローラー）更新がWSUS上で「Drivers（ドライバー）」分類として流れてくることがあります。ここで問題の更新を一度でも承認してしまうと、交換機がドメイン参加した直後にWSUSへアクセスし、同じ更新を取得して不具合が再現する、という事故が起きやすくなります。
よくある構成と“再配布”が起きる典型パターンは次のとおりです。
- GPOで「イントラネットのMicrosoft更新サービスの場所を指定する（WSUSを使う）」が設定されている
- クライアントは自動更新（スケジュールインストール）で運用されている
- 問題のドライバー更新が 「All Computers」または配布対象グループ に対して承認されている
- 端末交換後、ドメイン参加→GPO適用→WSUSスキャンが走り、承認済みドライバーが自動的に検出・インストールされる
まず整理：WSUSの「承認状態（Approval）」は3種類を使い分ける
「承認済みを取り消したい」と言ったときに混乱しやすいのが、WSUSには似た概念が複数ある点です。とくにNot Approved（未承認）とDeclined（拒否）は目的が違います。
| 状態 | WSUS上の意味 | クライアントへの影響 | 使いどころ |
|---|---|---|---|
| Approved（承認済み） | 指定したコンピューターグループに配布してよい | スキャン時に検出され、設定次第で自動インストールされる | 検証済みの更新を計画的に配布するとき |
| Not Approved（未承認） | そのグループに対しては配布しない（“普通の状態”） | スキャンしても提案されない（※既にインストール済みの端末からは自動で戻らない） | 誤って承認した更新を止めたい／特定グループだけ配布対象から外したいとき |
| Declined（拒否） | 更新自体を拒否扱いにする（強いブロック） | 原則として配布対象にできない扱いになる。運用・ポリシー上「二度と配りたくない」意思表示 | 危険な更新を明確に締め出したい／不要なドライバーを整理したいとき |
今回の要件は「承認済み（Approved）にしてしまったドライバー更新を、配布しない状態へ戻す」なので、まず狙うべきはNot Approved（未承認）へ戻すことです。Declineは便利ですが、運用ルールや将来の復旧手順（再承認の手間）まで含めて設計してからにすると安全です。
結論：WSUSは「Approve（承認）」の操作で Not Approved に変更できる
直感に反しているのですが、WSUSでは対象更新を右クリックして「Approve…（承認）」を開き、そのダイアログ内のプルダウンから「Not Approved」を選ぶことで、承認状態を未承認へ戻せます。つまり“未承認にするために承認メニューを開く”のが正しい手順です。
手順：ドライバー更新を見つけやすくしてから Not Approved に戻す
ドライバー更新は数が多く、通常の「All Updates」だと埋もれます。まずはドライバー専用ビューを作り、承認済みだけを一覧にしてから対象を特定します。
- WSUSコンソールを開き、左ペインで「Updates（更新）」を選びます。
- ドライバー用の更新ビュー（Update View）を作成します。
例：Updatesを右クリック → 「New Update View…（新しい更新ビュー）」 → 「Classifications」で「Drivers」を含めたビューを作る
ビュー名は「Drivers – Approved」など、目的が分かる名前にしておくと後で迷いません。 - 作成したビューを開き、右上（または一覧上部）のスコープ（Scope）で絞り込みます。
- Approval：Approved（承認済み）
- Status：Any（状態は任意）
- 一覧から問題のドライバー更新（例：Surface関連のドライバー/ファームウェア、特定ベンダーのグラフィックス/ネットワーク等）を探します。
タイトルでの並び替え、検索ボックス、列表示（Approval/Classification/Release Dateなど）を活用すると特定が速くなります。 - 対象の更新を右クリック → 「Approve…（承認）」を選択します。
- 表示された承認ダイアログで、該当コンピューターグループのプルダウンを「Not Approved（未承認）」に変更します。
承認先が「All Computers」になっていた場合は、その行をNot Approvedにします。特定グループだけ止めたい場合は、該当グループだけNot Approvedにし、他グループはApprovedのままにできます。 - 「OK」または「Apply」で確定します。ビューの一覧に戻ったら、承認列（Approval）がNot Approvedになっていることを確認します。
この操作で「今後のスキャンで、そのグループには提示しない」状態になります。端末交換後にドメイン参加したPCが自動で拾ってしまう状況を止めるには、まずここまでを最優先で実施するのが効果的です。
運用の要点：全社停止ではなく「グループ単位の未承認」が安全
WSUSの承認はコンピューターグループ単位で設定できます。たとえばSurface Pro 7だけに影響するドライバーなら、全端末を止めるのではなく、Surface用グループだけNot Approvedにするのが事故を広げないコツです。
| やりたいこと | 推奨する承認設定 | 理由 |
|---|---|---|
| Surface Pro 7だけ問題ドライバーを止めたい | Surfaceグループ：Not Approved それ以外：必要ならApproved | 影響範囲を限定し、他機種の更新運用を止めない |
| どの端末でも危険なので完全に止めたい | 全グループ：Not Approved（またはDeclineを検討） | 再発防止を最優先。緊急時はまず未承認化で止血 |
| 検証環境だけ先に当てたい | 検証グループ：Approved 本番グループ：Not Approved | ドライバー更新は端末依存が強いので段階展開が有効 |
端末がどのグループに入るかは、WSUSの「サーバー側ターゲット（手動でグループに移動）」か、GPO/レジストリで指定する「クライアント側ターゲット（Client-side targeting）」かで運用が変わります。どちらでも構いませんが、“交換機がどのグループに入った瞬間に問題ドライバーが見えるのか”を把握しておくと、再発を潰しやすくなります。
Not Approvedに戻したのに入ってしまうときのチェックポイント
承認状態を戻しても「交換直後にもう入ってしまった」「未承認にしたのに検出される」という場合は、次の切り分けが役に立ちます。
| 症状 | よくある原因 | 対処の方向性 |
|---|---|---|
| 既にインストール済み（不具合が再現している） | 未承認化より前にインストールされた／オフライン時にキューされていた | ドライバーのロールバック・アンインストール、復旧手順（セーフモード/回復環境）を優先 |
| ダウンロード済みでインストール待ち | 未承認化の前に検出・ダウンロードが完了していた | Windows Updateのキャッシュクリアや、インストールを止める措置を検討 |
| WSUSでは未承認なのに再び承認済みになる | 自動承認ルール（Auto Approval）がドライバーを承認している | 自動承認ルールを見直し、Drivers分類の自動承認を止める／例外運用にする |
| WSUSを止めたのにWindows Updateから入る | WSUS適用が外れている、もしくは端末が別経路で更新している | GPO適用状況、WUfB/Intune/他管理の設定、社外ネットワーク時の挙動を確認 |
WSUS側の設定変更は「次回スキャンから効く」のが基本です。端末側の状態によっては、未承認化しても“既に手元にある更新”を止めきれないことがあります。特にSurfaceのファームウェア系は戻しにくいことがあるため、未承認化（止血）→ 端末側の復旧の順で進めると被害を抑えやすくなります。
端末側での応急対応：既にドライバー更新が入った場合の考え方
WSUSの承認を戻すのは「これ以上広げない」ための施策です。一方で、既に更新が適用されて壊れている端末には、端末側の復旧が必要になります。環境・ドライバーの種類によって最適解は変わりますが、現場でよく使う考え方をまとめます。
- デバイスマネージャーの「ドライバーを元に戻す」が使えるなら優先（GPU/ネットワークなど、通常のドライバー更新で有効なことが多い）
- ロールバックできない場合はアンインストールや、デバイスの無効化で一時回避する（再起動や再検出で戻る場合は注意）
- ドライバーがINFとして残っている場合、管理者はpnputil等でドライバーパッケージの削除を検討できる（強制削除はリスクがあるため、復旧手順とセットで実施）
- ファームウェア更新が原因の疑いがある場合は、メーカー（Microsoft/ベンダー）の公式回復手順・イメージを優先する
参考として、ドライバーパッケージの確認に使われるコマンド例を載せます（実行は管理者権限）。
pnputil /enum-drivers
pnputil /delete-driver oemXX.inf /uninstall /force
ただし、Surfaceのようにファームウェア更新が絡む場合、上記だけで解決しないことがあります。端末が起動不能・暗号化（BitLocker）・回復キーなどの要素が絡むと復旧が急に難しくなるため、現場の手順書（交換・初期化・回復キー管理）を先に整備しておくのがおすすめです。
「Decline（拒否）」を使うべきケースと注意点
Not Approvedは「今は配らない」というニュアンスが強く、将来再評価して承認し直す可能性があるときに向きます。一方、“二度と配布したくない”レベルの危険な更新ならDeclineを選ぶ運用もあります。
- Declineが向くケース：明確に不具合が出る、業務端末を破損させる、脆弱性修正ではないのに影響が大きい、など
- 注意点：Declineは強い拒否のため、後から必要になった場合は手戻りが発生しやすい（運用上の復旧手順を決めてから採用する）
- 整理の副作用：Declineを多用すると、後々の棚卸しやクリーンアップが楽になる一方、判断ミスの影響も大きくなる
緊急時のセオリーは、まずNot Approvedに戻して配布を止め、影響範囲と原因が固まった段階でDecline運用へ移すかどうかを決める、という順番です。
再発防止のためのWSUS運用改善（ドライバー更新は“慎重すぎる”くらいでちょうどいい）
Windowsの品質更新（Quality Updates）と比べて、ドライバー更新は端末・周辺機器・BIOS/UEFIとの相性に左右されやすく、「少数の端末にだけ致命的」が起きやすい領域です。WSUSでドライバーを扱うなら、次のようなルール化が有効です。
ドライバー更新の基本方針（おすすめ）
- 原則：Drivers分類は自動承認しない（まずは検証→必要なものだけ手動承認）
- 機種別グループを作る（Surface、ノート、デスクトップ、特殊周辺機器など）
- 段階展開（検証グループ→先行本番→全体）を必ず挟む
- 承認の記録を残す（いつ、誰が、どの更新を、どのグループに承認したか）
- 問題が起きたら即「未承認化」で止血できるよう、ビューと検索の導線を整備する
実務で効く「ビュー」設計の例
ドライバーを扱うWSUSでは、ビューが整っているかどうかで対応速度が変わります。以下のように“事故対応ビュー”を用意しておくと、今回のような緊急対応が短時間でできます。
| ビュー名の例 | 分類 | Approval | Status | 用途 |
|---|---|---|---|---|
| Drivers – Approved | Drivers | Approved | Any | 「過去に承認したドライバー」を一覧で確認し、問題発生時にすぐ未承認化する |
| Drivers – Needed | Drivers | Any | Needed | 現時点で端末が必要としているドライバーを眺め、承認判断の材料にする |
| Drivers – Failed/Installed | Drivers | Any | Failed / Installed | 配布後の成否確認、失敗端末の洗い出しに使う |
よくある質問（現場で詰まりやすいポイント）
「Approve…」を開いても Not Approved が見当たりません
承認ダイアログは「コンピューターグループごと」に状態を選びます。グループの行が折りたたまれていたり、スクロール位置の都合で見落としやすいので、まずは承認対象グループ（All Computers/配布グループ）の行のプルダウンを確認してください。WSUSの表示言語によっては「Unapproved」「Not approved」と表記が揺れる場合もあります。
Not Approvedにしたのに、交換機がすぐ不具合を起こしました
端末側で、未承認化より前に更新検出・ダウンロードが完了していた可能性があります。事故が多発している状況なら、WSUSで止血しつつ、交換機をネットワークに接続する前にGPO適用（WSUS設定）や更新動作を制御するなど、展開手順側の見直しも有効です。たとえば「初回起動は隔離ネットワークで基本設定→テストグループにだけ参加→問題ないことを確認してから本番へ」という流れにすると、ドライバー起因の事故を減らせます。
対象ドライバーが見つかりません（一覧が多すぎる）
ドライバー更新はタイトルが似通うことが多く、製品名・バージョンだけでは判別しにくいことがあります。次の工夫が効きます。
- ビューを「Drivers」分類に絞り、Approvalを「Approved」にする（母集団を小さくする）
- リリース日（Release Date）やベンダー名、更新IDで絞り込む
- クライアント側のWindows Update履歴、イベントログ（WindowsUpdateClient）から“問題の更新名”を正確に拾い、WSUS検索に貼る
まとめ：事故を止める最短ルートは「承認ダイアログでNot Approvedへ戻す」
WSUSで誤って承認したドライバー更新は、コンソール上の「Approve…」操作からNot Approved（未承認）へ戻すのが最短です。特にSurface Pro 7のように、特定ドライバー/ファームウェア更新が端末不具合につながる環境では、ドライバーは段階展開・機種別グループ・手動承認を徹底すると、交換・再参加のたびに同じ事故が起きる状況を防げます。
まずは「Drivers – Approved」ビューを作り、問題更新を素早く見つけて未承認化できる状態を整えることから始めてみてください。
コメント