WSUS配下のドメイン参加PCで「OpenSSH Server」を追加しようとすると、進捗が止まったまま失敗することがあります。原因は“オプション機能（Features on Demand / Capability）”がWSUSではなくWindows Update（Microsoft Update）へ取りに行く挙動になり得るためです。切り分けと、GPO設定・オフライン対策までまとめます。
起きやすい症状：途中で止まる・最後に失敗する
まずは「何が起きているか」を言語化すると、調査が一気に楽になります。OpenSSH Server の追加で起きがちな症状は次のとおりです。
- 「設定」や PowerShell で OpenSSH Server を追加すると、一定のところで進捗が動かなくなる（長時間待っても完了しない）
- 最終的に「インストールに失敗しました」となる／再試行しても同じ
- 環境はドメイン参加、WSUS 配下（クライアントは原則インターネットに出られない）
| 入口 | 見え方 | よくあるキーワード／ヒント |
|---|---|---|
| 設定アプリ（オプション機能） | 「インストール中」から進まない／失敗 | 更新の取得先が内部（WSUS）で固定されている環境で発生しやすい |
| PowerShell（Add-WindowsCapability） | エラーコードが表示されることがある | 0x800f0954 が代表例（WSUS 環境での FoD 取得失敗の典型） |
| DISM（/Add-Capability） | 処理が止まる／ログにエラー | C:\Windows\Logs\DISM\dism.log、CBS.log を見ると原因が寄りやすい |
なぜWSUSがあるのに詰まるのか：OpenSSH Server は「オプション機能」扱い
結論から言うと、ここがハマりどころです。Windows の OpenSSH Server は、多くのバージョンで「役割/機能（Server Manager の Feature）」ではなく、オプション機能（Features on Demand / Windows Capability）として提供されます。
オプション機能は、セキュリティ更新（累積更新プログラム）とは配布の仕組みが違い、必要なペイロード（CAB 等）を“どこから取るか”が別ルートになります。WSUS は「更新プログラムの配布」には強い一方、オプション機能のペイロード供給は環境によっては別途考慮が必要です。
| 種類 | 代表例 | 主な取得元（イメージ） | WSUS 配下で詰まりやすいポイント |
|---|---|---|---|
| 更新プログラム | 月例パッチ、累積更新（LCU） | WSUS（社内） | WSUS が正しく配布できていれば動くことが多い |
| オプション機能（Capability / FoD） | OpenSSH Server、RSAT、言語機能など | Windows Update / Microsoft Update、または管理者が用意したソース | 「WSUS固定＋インターネット遮断」だと取得できず停止/失敗 |
| コンポーネント修復 | .NET 3.5 の有効化、SFC/DISM 修復 | Windows Update、またはインストールメディアのソース | 修復コンテンツも同じポリシーの影響を受ける |
つまり、「WSUS があるなら更新元は分かっているはず」という直感は更新プログラムには当てはまりますが、OpenSSH Server のようなオプション機能には当てはまらないケースがある、というのが答えです。
まずは切り分け：詰まっているのは“ネットワーク”か“ポリシー”か
いきなり対処を当てに行くより、次の2点を確認すると最短でゴールに近づきます。
- （A）クライアントが Windows Update / Microsoft Update に到達できる設計か（物理的・ネットワーク的に外へ出られるのか）
- （B）到達できる設計でも、ポリシーで遮断していないか（GPO で「インターネットの更新先に接続しない」等が有効になっていないか）
特に WSUS 環境では、次の遮断系ポリシーが「オプション機能の追加」にも影響して、失敗を引き起こします。
| 確認したいポリシー（代表例） | 有効だと起きること | OpenSSH Server への影響 |
|---|---|---|
| Windows Update のインターネットの場所に接続しない | Windows Update への外部接続を禁止 | FoD を外部取得する必要がある場合に失敗しやすい |
| すべての Windows Update 機能へのアクセスを削除する | UIや機能アクセスを抑止 | 設定アプリからの追加がそもそもできない／挙動が不安定になりやすい |
| オプション コンポーネントのインストールとコンポーネント修復の設定を指定する | FoD や修復コンテンツの取得先を制御 | ここで外部取得を許可できる（または社内ソースを指定できる） |
対処法：GPO で「オプション機能は Windows Update から取得してよい」を許可する
インターネット（またはプロキシ経由）で Windows Update / Microsoft Update に到達できる設計なら、もっとも手戻りが少ないのはこの方法です。ポイントは“WSUS を使う/使わない”を更新プログラムとオプション機能で分けて考えることです。
設定するポリシー（概念）
グループポリシーで、オプションコンポーネント（FoD）と修復コンテンツの取得先に関する設定を有効化し、「WSUS ではなく Windows Update から直接ダウンロードする」を許可します。
パス（例）
コンピューターの構成 → 管理用テンプレート → システム → 「オプション コンポーネントのインストールとコンポーネント修復の設定を指定する」
ポリシー画面の文言は OS 世代や言語で微妙に違いますが、狙いは次のチェック項目です。
- 修復コンテンツやオプション機能を、WSUS ではなく Windows Update からダウンロードすることを許可
- （必要に応じて）代替ソースパス（Alternate source file path）を指定
実務で迷わないための手順（GPMC / gpedit）
- GPMC（グループポリシーの管理）で対象 OU に紐づく GPO を編集（または新規作成）
- 上記のポリシーを「有効」にし、外部取得を許可するチェックを入れる
- 同じ GPO（または別 GPO）で、遮断系ポリシーが「有効」になっていないか確認し、必要に応じて「未構成／無効」にする
- クライアントで
gpupdate /forceを実行（または再起動） - OpenSSH Server の追加を再実行
「Computer Configuration（コンピューターの構成）はどこ？」という質問もよく出ますが、これはローカルグループポリシー エディター（gpedit.msc）、またはGPMC で GPO を編集したときに表示されるツリーの最上位ノードです。「コンピューターの管理」画面内の項目ではありません。
PowerShell でのインストール例（確認にも便利）
GUI が制限されている環境では、PowerShell で能力（Capability）を確認して追加すると状況が見えやすくなります。
## OpenSSH 関連の Capability を確認
Get-WindowsCapability -Online | Where-Object Name -like 'OpenSSH*' | Select-Object Name, State
## OpenSSH Server を追加（オンライン取得）
Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0 成功したら、サービス起動・自動起動・FW ルールまで一気に整えると運用が安定します。
Start-Service sshd
Set-Service -Name sshd -StartupType Automatic
## 既定の FW ルールが作成されていれば有効化
Get-NetFirewallRule -DisplayName '*OpenSSH*' | Enable-NetFirewallRule
## 22番ポート待受の確認（例）
Get-NetTCPConnection -LocalPort 22 -State Listen インターネットに出られない前提が強い場合：現実的な2パターン
ここが“設計の分岐点”です。GPO で外部取得を許可しても、物理的に外へ出られない（プロキシもない／FWで完全遮断）なら、当然ながらペイロードを取れずに失敗します。その場合は、次のどちらかが現実的です。
| パターン | 何をするか | メリット | デメリット/注意 |
|---|---|---|---|
| (A) 一時的に外部へ出す | プロキシ許可や FW 例外で Windows Update への通信を許可し、インストール後に閉じる | 作業が早い／公式の入手経路で完結 | セキュリティ審査が必要になりやすい／例外範囲の設計が必要 |
| (B) 社内にソースを用意 | Features on Demand（FoD）やインストールメディアを共有配置し、Source 指定で追加する | 完全閉域でも実現可能／変更管理しやすい | OS ビルド/言語に合うメディア管理が必要／ストレージと手順整備が必要 |
(A) 一時的に Windows Update / Microsoft Update へ到達できる出口を用意する
「恒久的にインターネット禁止」ではなく、必要な期間だけ例外を作れるなら、現場の負担が小さいです。実務的には次のような落としどころが多いです。
- 対象端末（または踏み台サーバー）だけ、限定期間でプロキシを通す
- 通信先を Windows Update 系のみに絞り、一般Web閲覧はさせない
- 導入後は例外を戻し、以降の運用は鍵配布や設定管理に集中する
ネットワーク許可範囲は組織のポリシーが最優先です。Windows Update の到達性が担保できたら、前述の GPO 設定を有効化したうえでインストールを実施します。
(B) オプション機能（FoD）のソースを社内に用意して Source 指定で追加する
閉域で確実に通すなら、この方法が“筋が良い”です。ポイントはOS のエディション/ビルド/言語に合うソースを用意すること。ズレると「ソースが見つからない」「適用できない」系のエラーになりやすいです。
やることの全体像
- 対象 OS に合う Features on Demand（FoD）またはインストールメディアを準備（ISO など）
- ファイルサーバーに共有（例：
\\fileserver\sources\FOD\） - クライアントから /Source を指定して OpenSSH Server を追加（必要なら /LimitAccess で外部アクセスを抑止）
DISM の例（閉域向け）
DISM /Online /Add-Capability /CapabilityName:OpenSSH.Server~~~~0.0.1.0 ^
/Source:\\fileserver\sources\FOD\ ^
/LimitAccess
PowerShell の例（閉域向け）
Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0 `
-Source '\\fileserver\sources\FOD\' `
-LimitAccess
また、GPO の「オプション コンポーネントのインストールとコンポーネント修復の設定を指定する」には、代替ソースパス（Alternate source file path）を設定できる項目があります。ここに社内共有パスを入れておけば、端末側の作業を“追加するだけ”に寄せられます。
詰まったときに見る場所：ログと代表的なエラーコード
「止まっている」ように見えるときも、裏ではリトライ待ちや取得失敗を繰り返していることがあります。原因究明はログが最短です。
- DISM ログ：
C:\Windows\Logs\DISM\dism.log - コンポーネントベース サービス（CBS）ログ：
C:\Windows\Logs\CBS\CBS.log - イベントビューア：WindowsUpdateClient、Setup など（OS により差）
| エラー/状況 | 意味（よくある解釈） | 対処の方向性 |
|---|---|---|
| 0x800f0954 | WSUS 構成下で FoD の取得ができない/ブロックされている | GPOで外部取得を許可、または /Source 指定（閉域） |
| 0x800f081f / ソースが見つからない | 参照したメディアが合っていない／必要ファイルがない | FoD/ISO のビルド・言語一致を見直す、Source パスを再確認 |
| 長時間「インストール中」で止まる | 外部取得のタイムアウト/リトライ待ちの可能性 | ネットワーク到達性、遮断系GPO、プロキシ設定を確認 |
実務のコツとして、まず PowerShell の Add-WindowsCapability を試すと、GUI よりもエラーコードが見えやすく、原因が「取得できないのか」「ソースが合っていないのか」を切り分けやすいです。
一時的な検証としての“WSUS無効化”はアリだが、恒久対策にはしない
検索すると「レジストリで UseWUServer を 0 にして WSUS を外し、インストール後に戻す」という回避策が出てきます。確かに切り分けには有効ですが、ドメイン環境では GPO が再適用されて戻ったり、更新運用の統制が崩れるリスクがあります。あくまで“原因切り分けの一手”として使うのが安全です。
## 例：一時的に WSUS を使わない（検証用途）
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" /v UseWUServer /t REG_DWORD /d 0 /f
net stop wuauserv
net start wuauserv
恒久対策は、この記事で紹介しているようにGPO で「オプション機能の取得」だけを適切に許可/制御する、または社内ソースを用意して閉域で完結させるのが王道です。
Windows Server 2016 での注意点：そもそも「標準の OpenSSH Server」が前提とズレる場合
追加情報として「Windows Server 2016 を使っている」ケースでは、もう一段注意が必要です。OpenSSH が OS 標準のオプション機能として整備されているのは、一般にWindows 10（1809以降）や Windows Server 2019/2022で扱いやすいことが多く、Server 2016（特に LTSC 1607）では状況が異なります。
- Server 2016 では、GUI で「OpenSSH Server」が素直に出てこない、または入れ方が異なる場合がある
- 結果として「WSUS/FoD の問題」以前に、OS 世代差（提供形態の違い）が原因になっている可能性がある
もし Server 2016 で OpenSSH を標準機能として統一したいなら、運用面では次が現実的です。
- 可能なら Server 2019/2022 へ寄せる（標準機能として扱いやすく、GPO/FoD の設計も素直）
- Server 2016 を継続するなら、社内配布可能な形（承認済みパッケージ、共有配置、構成管理）で導入手段を用意する
「今の端末/サーバーがどの系統か」を確認するには、次のような情報が役立ちます。
winver
## もう少し詳細に
Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumber 運用で失敗しないための補足：導入後に確認すべきポイント
OpenSSH Server は「入ったら終わり」ではなく、運用上の最低限の確認が重要です。特にドメイン環境では、後から「接続できない」「鍵が通らない」「FWで落ちる」が起きがちです。
| 確認項目 | チェック内容 | コマンド例 |
|---|---|---|
| サービス | sshd が起動し、自動起動になっている | Get-Service sshd |
| FW ルール | 22/TCP を許可するルールが有効 | Get-NetFirewallRule -DisplayName '*OpenSSH*' |
| 待受 | 22 番で LISTEN している | Get-NetTCPConnection -LocalPort 22 -State Listen |
| ログ | 接続失敗時に原因が残る | Get-EventLog（環境により） |
また、端末により「既定でパスワード認証を許可する/しない」「鍵の置き場所」「ドメインアカウントでのログオン」など運用ポリシーが変わります。導入時は “最小限の動作確認→運用基準に合わせてハードニング” の順に進めると事故が減ります。
まとめ：WSUS環境で OpenSSH Server を確実に入れるための考え方
- OpenSSH Server は多くの環境でオプション機能（FoD / Capability）として配布され、WSUS とは別ルートで取得しようとすることがある
- WSUS 配下でインターネット遮断が強いと、ペイロード取得に失敗してインストールが止まる/失敗する
- 到達性が確保できるなら、GPO で「修復コンテンツやオプション機能を Windows Update から直接取得する」を許可する
- 完全閉域なら、FoD/メディアを社内共有し、/Source 指定（+LimitAccess）で閉域完結させる
- Windows Server 2016 は提供形態が異なる場合があるため、OS 世代差も含めて設計する
「WSUS があるのに詰まる」のは矛盾ではなく、“更新プログラム”と“オプション機能”で取得経路が違うことが原因です。ここを押さえると、OpenSSH だけでなく RSAT や .NET 3.5 などの導入トラブルも同じ考え方で整理できるようになります。
コメント