ConfigMgr（Configuration Manager）でSUP（Software Update Point）を構成しようとしたとき、「WSUS コンソール（管理ツール）をサイトサーバーに入れてください」と言われて戸惑うケースがよくあります。検索すると“WSUS のダウンロード先”ばかりが出てきてリンク切れや別ページ誘導に迷子になりがちですが、実は入手の考え方が違います。この記事では、WSUS コンソールの正しい入れ方と、ConfigMgr/SUPでハマりやすいポイントをまとめて解説します。
よくある悩み：WSUS の入手先を探しても見つからない
新規に ConfigMgr を構築し、ソフトウェア更新を担当する SUP を追加しようとすると、前提条件チェックや構築手順の中で「WSUS 管理コンソール（WSUS Console / WSUS Administration Console）」のインストールが話題に上がります。
ところが、いざ「WSUS コンソール ダウンロード」「WSUSSetup-x64.exe 入手」などで検索しても、古い情報やリンク切れが多く、次のような状態になりやすいです。
- WSUS のインストーラー（exe）を探して彷徨ってしまう
- “RSAT”や“Update Catalog”など別の話題に誘導される
- 「結局どこから取るのが正解？」が分からず作業が止まる
結論：WSUS コンソールは「単体ダウンロード」ではなく Windows Server の機能追加で入れる
まず押さえるべき結論はこれです。
WSUS コンソール（管理ツール）は、基本的に “単体のダウンロードリンクを探すもの” ではありません。Windows Server の「役割/機能」として追加するのが正攻法です。
言い換えると、WSUSSetup-x64.exe を見つけようとするアプローチは、現在の Windows Server 世代では遠回りになりやすい、ということです。
| やりたいこと | やりがちな行動 | 正しいアプローチ |
|---|---|---|
| サイトサーバーに WSUS コンソールを入れたい | 「WSUS ダウンロード」を探して exe を探す | Windows Server の役割/機能（管理ツール）として追加する |
| SUP 用の WSUS を用意したい | WSUS を別製品のように導入しようとする | SUP サーバーに WSUS 役割、サイトサーバーに WSUS コンソールを入れる |
| インストールできたか確認したい | コントロールパネルを探す | サーバーマネージャーの「ツール」や WindowsFeature/PowerShell で確認する |
「WSUS コンソール」とは何か：管理 UI だけではなく API も含む
ConfigMgr の文脈で言う「WSUS コンソール」は、単に GUI の管理画面だけを指していないことがあります。多くの環境で必要になるのは次の要素です。
- WSUS 管理コンソール：MMC スナップインとして動く管理 UI（サーバーマネージャーの［ツール］から起動できるもの）
- WSUS API / PowerShell コマンドレット：ConfigMgr が WSUS と連携するために必要になる管理コンポーネント
GUI だけ入っているつもりでも、API 側が不足していると ConfigMgr の前提条件チェックや連携でつまずくことがあります。機能追加の画面で「WSUS ツール」「WSUS 管理ツール」など、ツール一式を選ぶ意識が大切です。
そもそもなぜ ConfigMgr / SUP で WSUS コンソールが必要なのか
「WSUS は SUP サーバーに入れるのでは？」「なぜサイトサーバーにも？」という疑問が出るのは自然です。ここを理解すると、構成の意図がはっきりします。
ConfigMgr のソフトウェア更新は、内部的に WSUS（Windows Server Update Services）の仕組みを利用します。SUP を追加すると、ConfigMgr は WSUS の API（管理用コンポーネント）を使って同期やメタデータ管理を行います。
そのため、SUP のある環境では「WSUS の役割（更新サービス本体）」と「WSUS の管理ツール（コンソール/API）」を適切なサーバーに入れておく必要があります。特に「サイトサーバー側に管理ツールが必要」という点が見落とされがちです。
| サーバー | 入れるもの | 目的 | よくある勘違い |
|---|---|---|---|
| SUP サーバー（Software Update Point） | WSUS 役割（Update Services） | 更新メタデータの同期・提供の基盤 | 「WSUS コンソールも必ずここに入れる」 |
| ConfigMgr のサイトサーバー（プライマリサイト） | WSUS 管理ツール（WSUS コンソール/API） | ConfigMgr が WSUS API を利用して管理するため | 「WSUS は別サーバーだからサイトサーバーには不要」 |
構成によっては、SUP サーバー＝サイトサーバー（同一サーバー）ということもあります。その場合は同一サーバーに両方入りますが、別サーバー構成でもサイトサーバーに管理ツールが必要という点が重要です。
SMS Provider を別サーバーに置いている場合はそこも要注意
ConfigMgr の構成によっては、SMS Provider（SMS プロバイダー）をサイトサーバーとは別のサーバーに分離していることがあります。もしこの構成を取っている場合、WSUS 管理ツール（コンソール/API）が必要なのは「サイトサーバー」だけでなく「SMS Provider を持つサーバー」も対象になることがあります。
「サイトサーバーには入れたのにまだ前提条件エラーが消えない」「SUP の追加が進まない」といったときは、SMS Provider の配置を確認し、分離しているならそちらのサーバーにも同様に WSUS ツールを追加する、という視点を持つと解決が早まります。
インストール前に確認しておきたいこと
作業を最短で終わらせるために、まず次の確認から入るのがおすすめです。
- どのサーバーに WSUS コンソールを入れるのか：基本は「ConfigMgr のサイトサーバー（必要に応じて SMS Provider サーバー）」
- SUP と WSUS は同居か別居か：別居なら SUP 側には WSUS 役割、サイトサーバーには管理ツール
- OS は Windows Server か：本記事は Windows Server 上での手順を中心に解説
この3点が曖昧なまま進むと、不要なサーバーに役割を入れてしまったり、逆に必要な管理ツールが欠けたまま SUP の前提条件チェックに失敗したりします。
手順：サーバーマネージャーで WSUS コンソール（管理ツール）を追加する
もっとも分かりやすいのは GUI（サーバーマネージャー）での追加です。Windows Server のバージョンによって表示名が少し異なることがありますが、狙いは同じです。
- 対象サーバー（通常はプライマリサイトサーバー）に管理者でサインインします。
- サーバーマネージャーを開き、右上の ［管理］→［役割と機能の追加］ を選びます。
- ウィザードを進めて ［機能］（または WSUS を入れる場合は役割の途中）まで到達します。
- 次のいずれかの項目を探してチェックします（表示名は環境で変動します）。
- Windows Server Update Services ツール
- WSUS ツール
- WSUS 管理コンソール（Administration Console）
- WSUS API と PowerShell コマンドレット（選べる場合）
- そのまま進めてインストールを完了します（再起動が促される場合は指示に従います）。
インストール後、サーバーマネージャー上部の ［ツール］ メニューに ［Windows Server Update Services］ が表示されれば、WSUS コンソール（管理 UI）が入った可能性が高いです。
「WSUS 役割を入れていないのに管理ツールだけ入るの？」
この疑問もよくあります。一般的には、WSUS の管理ツール（コンソール/API）だけを追加できるケースが多く、ConfigMgr のサイトサーバーにはそれで十分なことが多いです。
一方で、環境によっては「WSUS 役割を追加する流れの中で管理ツールにチェックを入れる」形になっている場合もあります。迷った場合は、目的は “サイトサーバーに WSUS 管理ツールを入れること”と覚えておくと、画面の表記ゆれに振り回されにくくなります。
手順：PowerShell で WSUS コンソールを追加する（GUI が苦手な人向け）
手順書を残したい、同じ作業を繰り返したい、Server Core に近い運用をしている、といった場合は PowerShell での導入が便利です。
まず、WSUS 関連の機能名を確認します。
Get-WindowsFeature *UpdateServices*一覧の中に、次のような項目が見えることが多いです（代表例）。
- UpdateServices（WSUS 役割）
- UpdateServices-UI（WSUS 管理コンソール）
- UpdateServices-API（WSUS API）
サイトサーバーに「管理コンソール」を入れたい場合は、次のようにインストールします（名称は環境の一覧に合わせてください）。
Install-WindowsFeature UpdateServices-UISUP サーバーに WSUS 役割も含めて入れるなら、次のような形になります。
Install-WindowsFeature UpdateServices -IncludeManagementToolsインストール後の確認は、次のコマンドが手早いです。
Get-WindowsFeature *UpdateServices* | Where-Object {$_.InstallState -eq 'Installed'}「WSUSSetup-x64.exe」を探してしまう理由と、迷子にならない検索のコツ
WSUS を探していると、「WSUSSetup」「WSUS 3.0」「スタンドアロンの WSUS」など、古い世代の情報が検索上位に出てくることがあります。これは歴史的経緯が原因です。
過去には、WSUS を単体インストーラーで導入するケースがあり、その名残で “exe をダウンロードするもの” だと思い込みやすい状況が残っています。しかし現在の Windows Server 世代では、WSUS は基本的にサーバー機能の一部として提供されます。
| 検索で見かける単語 | 意味 | 今の判断 |
|---|---|---|
| WSUSSetup-x64.exe | 古い配布形態でのインストーラー名として話題になりやすい | 現行の Windows Server では「役割/機能」で導入するのが基本 |
| WSUS 3.0 / WSUS 3.0 SP2 | かなり古い世代の WSUS | ConfigMgr/SUP の前提としては避けるべき（情報の鮮度に注意） |
| RSAT: WSUS Tools | クライアント OS から管理用ツールを入れる仕組み | 「管理目的」には便利だが、サイトサーバーの前提条件とは別物になりやすい |
ポイントは、「WSUS をダウンロードする」のではなく「Windows Server に機能として追加する」という発想に切り替えることです。これだけで、リンク切れの探索や無関係なページ回遊を大幅に減らせます。
参考：管理端末（Windows 10/11）から WSUS を触りたい場合は RSAT という選択肢もある
ここまでの話は「ConfigMgr のサイトサーバーに必要な WSUS 管理ツール」が主題です。一方で、運用では管理端末（Windows 10/11）から WSUS の管理 UI を開きたい場面もあります。
その場合は RSAT（Remote Server Administration Tools）で WSUS ツールを追加できることがあります。ただし、RSAT は “管理用の端末に入れるもの” であって、ConfigMgr の前提条件を満たすためにサイトサーバーへ入れるものとは別になりやすいので、目的を混同しないようにしてください。
インストール後の確認ポイント（“入ったつもり” を防ぐ）
WSUS 管理ツールを入れたつもりでも、チェックの入れ忘れや機能の未選択で「入っていない」状態になっていることがあります。次のチェックで短時間に切り分けできます。
サーバーマネージャーで確認
- サーバーマネージャーの ［ツール］ に ［Windows Server Update Services］ が出ている
- ［役割と機能の追加］→［機能］で WSUS ツール／管理コンソールが有効になっている
ファイル/ショートカットで確認
- スタートメニューに「Windows Server Update Services」関連が追加されている
- 環境によっては
wsus.msc（管理スナップイン）が存在する
PowerShell で確認
Get-WindowsFeature UpdateServices-UIInstallState が Installed であれば、少なくとも機能としては導入できています。
ConfigMgr 側で起きやすいエラーと、WSUS コンソール不足の見分け方
SUP の追加や同期でつまずいたとき、原因が「WSUS コンソール未導入」なのか「別の前提条件」なのかを切り分けるのが重要です。よくある症状を整理します。
| 症状 | ありがちな原因 | まずやる対処 |
|---|---|---|
| SUP 追加時の前提条件チェックで失敗する | サイトサーバー（または SMS Provider サーバー）に WSUS 管理コンソール/API が入っていない | 該当サーバーに「WSUS ツール/管理コンソール」を機能追加する |
| 同期は動くが、WSUS 連携関連で警告が出る | WSUS の管理コンポーネントが不足、またはバージョン不整合 | UpdateServices-UI/API の導入状況を PowerShell で再確認する |
| WSUS コンソールが起動できない/接続できない | 接続先（WSUS サーバー）のポート・証明書・サービス状態の問題 | まずは WSUS サービス起動と 8530/8531 の通信、IIS/証明書を確認する |
特に最初の「前提条件チェックで失敗」は、今回のテーマと直結することが多いです。“WSUS が入っているか” ではなく “WSUS の管理ツールが必要なサーバーに入っているか”に注目すると解決が早まります。
SUP/WSUS を分離構成にする場合の「どこに何を入れるか」早見表
ConfigMgr の構成では、SUP を別サーバーに分けるケースがよくあります。分離構成のときに混乱しやすいので、あらかじめ整理しておきましょう。
| 構成パターン | サイトサーバー（プライマリ） | SUP サーバー | ポイント |
|---|---|---|---|
| 同居（検証・小規模） | WSUS 役割 + WSUS 管理ツール | （同一） | 簡単だが役割が集中。運用負荷と性能に注意。 |
| 分離（一般的） | WSUS 管理ツール（コンソール/API） | WSUS 役割（Update Services） | サイトサーバーの「管理ツール不足」が最頻出の落とし穴。 |
| 複数 SUP（拠点/境界） | WSUS 管理ツール（コンソール/API） | 各 SUP に WSUS 役割 | WSUS の設定は基本的に ConfigMgr 側で統制する。 |
WSUS コンソールを入れた後にやってはいけない（やりがち）設定
WSUS コンソールが起動できるようになると、つい WSUS 側の画面でいろいろ設定したくなります。しかし ConfigMgr と SUP を使う運用では、WSUS 側を手で触ると逆に不整合の原因になることがあります。
基本方針としては、更新の承認・製品/分類・同期スケジュールなどは ConfigMgr 側で管理し、WSUS コンソールは「状態確認」や「トラブルシュート補助」に留めるのが安全です。
| 項目 | 触ってよい？ | 理由（運用の考え方） |
|---|---|---|
| 製品/分類の選択 | 基本的に触らない | ConfigMgr のソフトウェア更新ポイント設定で管理する |
| 承認（Approve） | 触らない | 配布/展開の制御は ConfigMgr で行う |
| 同期スケジュール | 基本的に触らない | 同期は ConfigMgr の同期設定が主 |
| 接続確認・サービス状態の確認 | 必要に応じて触る | 障害時の切り分けに役立つ |
| クリーンアップ（不要更新の整理） | 慎重に | 効果はあるが、運用方針とバックアップ前提で実施 |
よくある質問
WSUS コンソールを入れたのに、ConfigMgr の前提条件エラーが消えません
まず「どのサーバーに入れたか」を確認してください。多くのケースで、WSUS 役割を入れた SUP サーバーだけにツールを入れてしまい、サイトサーバー（または SMS Provider サーバー）に WSUS 管理ツールが入っていないことが原因になります。分離構成では特に発生しやすい落とし穴です。
WSUS のコンソールは入れました。WSUS の初期設定ウィザードも進めるべきですか？
ConfigMgr/SUP の運用では、WSUS 側の設定をむやみに進めるより、ConfigMgr 側の SUP 設定・同期設定に沿って構成する方が安全です。WSUS のウィザードやコンソールでの詳細設定は、障害切り分け以外では最小限に留めるのが無難です。
“WSUS のコンソールが必要” と言われたら、どの機能名を入れればいいですか？
GUI では「Windows Server Update Services ツール」「WSUS ツール」「WSUS 管理コンソール」など、表記が揺れることがあります。PowerShell なら Get-WindowsFeature *UpdateServices* で候補を出し、UpdateServices-UI（管理コンソール）を中心に、必要に応じて API も含むツール一式を入れるのが分かりやすいです。
現場で役立つ：インストール作業を最短化するチェックリスト
最後に、作業を迷いなく進めるためのチェックリストを置いておきます。手順書化する場合はそのまま貼り付けても使える形にしてあります。
- 対象は「プライマリサイトサーバー（サイトサーバー）」である（SMS Provider を分離しているならそのサーバーも対象）
- サーバーマネージャーの［役割と機能の追加］から「WSUS ツール／WSUS 管理コンソール」を追加する
- PowerShell なら
Get-WindowsFeature *UpdateServices*で機能名を確認してから導入する - インストール後、サーバーマネージャー［ツール］に WSUS が表示されることを確認する
- ConfigMgr の SUP 前提条件チェックを再実行して通ることを確認する
まとめ：WSUS コンソールは“リンクを探す”のではなく“機能として追加する”
WSUS コンソールの入手先が分からない問題は、情報が古いほど「単体ダウンロード」へ誘導されやすいことが原因です。ConfigMgr/SUP の文脈では、Windows Server の役割/機能として WSUS 管理ツールを追加するのが基本で、これが最短ルートです。
もし今まさに「WSUS の exe が見つからない」と迷っているなら、検索タブを閉じてサーバーマネージャーを開くのが近道です。サイトサーバーに管理ツールを入れ、SUP の前提条件をクリアして、ソフトウェア更新の同期まで一気に進めましょう。
コメント