Windows Server 2012 の WSUS で在宅勤務（VPN）端末を更新管理していると、「グループ別の適用率レポートを毎月出したい」「VPN なのに自動で検出・同期しない」「承認は WSUS で、更新ファイルはインターネットから落としたい」といった“現場の困りごと”が連鎖しがちです。ここでは WSUS の標準機能でできること／できないことを整理し、運用で寄せる方法と PowerShell でのレポート自動化案まで具体的にまとめます。
WSUS で「在宅勤務ユーザー用コンピューターグループ」を作る前提
在宅勤務端末を WSUS で扱うときは、まず「端末をどのグループに所属させるか」を確実に決めておくのが重要です。WSUS には大きく分けて、管理者が WSUS コンソールで端末を振り分けるサーバー側ターゲティングと、GPO/レジストリで端末自身が所属グループ名を申告するクライアント側ターゲティングがあります。クライアント側ターゲティングにすると、在宅勤務端末が増減しても OU と GPO の設計で吸収しやすく、運用負荷が下がります。
クライアント側ターゲティングを使う場合、WSUS 側で「GPO/レジストリでのグループ指定を使う」設定に切り替え、WSUS コンソールで目的のグループ（例：在宅勤務ユーザー用コンピューターグループ）を作成します。
| 項目 | おすすめ | 理由 |
|---|---|---|
| グループ割り当て方式 | クライアント側ターゲティング | OU/GPO と相性がよく、在宅勤務端末の追加・入替に強い |
| WSUS への接続方式 | VPN で社内到達、または外部到達（SSL） | 在宅端末は「到達できない時間」が増えるため、到達性の設計が肝 |
| WSUS 既定ポート | 8530/8531（既定） | クライアントは WSUS へアウトバウンドで 2 ポート到達が必要（既定 8530/8531） |
課題：グループ別に「承認済み更新の適用率レポート」を毎月出したい
よくある要求仕様（“管理要件どおりの体裁”問題）
相談が多いのは、次のような“指定フォーマット”を月次で出したいケースです。
- コンピューター名
- 承認済み更新数
- 未適用（必要／保留）更新数
- 失敗した更新数
- 承認済み更新の適用率（％）
ここでポイントになるのが、「WSUS 標準レポートの列」≠「現場が欲しい列」になりやすいことです。WSUS の組み込みレポートは便利ですが、列の追加や独自の“適用率（%）”の定義をそのまま出す、といった用途には向きません。
結論：WSUS “標準機能だけ”で、要求どおりの「月次カスタムレポート自動生成」手段は用意されていない
WSUS コンソールの標準レポート機能は固定フォームが中心で、管理要件どおりに列を並べ替えて「グループ別に CSV を毎月自動出力」までを“公式の既成手段”として揃えているわけではありません。そのため、現実的な落としどころは次のどれかになります。
- 標準レポートで近い情報を出し、Excel 等で加工して運用要件に寄せる
- WSUS API / PowerShell でレポートを自作し、自動化する（SQL を直接叩かずに済む）
- どうしても複雑な集計が必要なら、DB 参照（SQL）も検討するが、保守・サポート観点の注意が増える
まず確認：WSUS 標準レポートでどこまで“近い形”にできるか
WSUS の標準レポートでは、端末別に「必要」「インストール済み」「失敗」「不明」といった状態サマリを確認できます。一方で、あなたの要件（承認済み更新数、適用率% など）を“そのまま 1 行で出す”のは難しいことが多いです。
| 欲しい項目 | WSUS 標準レポートでの出しやすさ | 補足 |
|---|---|---|
| コンピューター名 | ◎ | 端末別レポートで出せる |
| 未適用（必要／保留）更新数 | ○ | 「必要」相当で近い値は取れる |
| 失敗した更新数 | ○ | 「失敗」相当で近い値は取れる |
| 承認済み更新数 | △ | “承認済み”だけに絞った集計や、適用対象（Applicable）だけの集計は工夫が必要 |
| 適用率（％） | △ | 分母・分子の定義を決めて自前計算が必要 |
運用で寄せる：標準レポート出力 → 加工で「適用率」を作る
「SQL は触れないが、毎月の報告体裁は揃えたい」という場合、まずは標準レポートのエクスポートをベースに、Excel/PowerQuery 等で定型加工するのが現場では最短ルートです。特に在宅勤務端末は「しばらく WSUS に報告していない端末」が混ざりやすく、そういう端末を“適用率100%”として扱ってしまうと報告の信頼性が落ちます。
この運用で押さえるべきコツは次の 2 点です。
- 適用率の定義を固定する（例：Installed と PendingReboot を「適用済み」に含めるか）
- 不明（Unknown）をどう扱うかを決める（在宅端末は Unknown が増えやすい）
自作で寄せる：WSUS API + PowerShell で「グループ別・端末別」CSV を自動生成する
SQL を直接触らずに、WSUS の API 経由で集計値を取るなら、PowerShell が最も現実的です。WSUS API には、指定した更新集合と端末集合に対して、端末ごとのサマリ（InstalledCount、NotInstalledCount、FailedCount など）を返す仕組みがあります。
さらに UpdateScope には「どのターゲットグループに対して承認されている更新を対象にするか」を絞り込むプロパティがあり、在宅勤務グループだけの“承認済み更新”に寄せた集計も可能です。
「承認済み更新の適用率」を計算する前に決めること
適用率（%）は、計算式を決めないとブレます。特に WSUS のサマリには次の状態が混ざります。
| 状態 | WSUS サマリの代表プロパティ | 意味（ざっくり） | 適用率の扱い例 |
|---|---|---|---|
| 適用済み | InstalledCount | インストール完了 | 分子に入れる |
| 適用済み（要再起動） | InstalledPendingRebootCount | インストール済だが再起動待ち | 分子に入れる／別列で管理（推奨） |
| 保留（DL 済み） | DownloadedCount | ダウンロード済みで未インストール | 未適用にカウント |
| 未適用 | NotInstalledCount | 適用対象だが未DL/未インストール | 未適用にカウント |
| 失敗 | FailedCount | インストール失敗 | 失敗列にカウント |
| 不明 | UnknownCount | 状態不明（未報告など） | 在宅勤務では「未適用扱い」にすると報告が保守的になる |
| 対象外 | NotApplicableCount | その端末に不要 | 分母から除外 |
本記事では、在宅勤務端末の実務に合わせて、Unknown（不明）を未適用に含める形で計算します。VPN で報告が遅れた端末が“適用済み扱い”になるのを防ぐためです。
PowerShell サンプル：在宅勤務グループの「承認済み更新 適用率」CSV を出す
次の例は、WSUS API で「在宅勤務ユーザー用コンピューターグループ」配下の端末について、承認済み更新のサマリを取り、指定の列で CSV 出力します。WSUS 管理コンソール（API アセンブリ）にアクセスできる環境で実行してください。
param(
[string]$WsusServer = "WSUS01",
[int]$Port = 8530,
[switch]$UseSSL,
[string]$TargetGroupName = "在宅勤務ユーザー用コンピューターグループ",
[string]$OutCsv = "C:\Reports\WSUS_RemoteWork_Compliance.csv"
)
# WSUS API を読み込み
[void][reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration")
# WSUS に接続
$wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer($WsusServer, [bool]$UseSSL, $Port)
# 対象グループ取得
$group = $wsus.GetComputerTargetGroups() | Where-Object { $_.Name -eq $TargetGroupName }
if (-not $group) {
throw "WSUS コンピューターグループが見つかりません: $TargetGroupName"
}
# 端末スコープ（グループで絞る）
$computerScope = New-Object Microsoft.UpdateServices.Administration.ComputerTargetScope
$computerScope.IncludeSubgroups = $true
$null = $computerScope.ComputerTargetGroups.Add($group)
# 更新スコープ（承認済み、かつ当該グループへの承認に限定）
$updateScope = New-Object Microsoft.UpdateServices.Administration.UpdateScope
$updateScope.ApprovedStates = [Microsoft.UpdateServices.Administration.ApprovedStates]::LatestRevisionApproved
$updateScope.UpdateApprovalActions = [Microsoft.UpdateServices.Administration.UpdateApprovalActions]::Install
$null = $updateScope.ApprovedComputerTargetGroups.Add($group)
# 端末別のサマリ取得
$summaries = $wsus.GetSummariesPerComputerTarget($updateScope, $computerScope)
# レポート整形
$report = foreach ($s in $summaries) {
$computer = $wsus.GetComputerTarget([guid]$s.ComputerTargetId)
$installed = $s.InstalledCount + $s.InstalledPendingRebootCount
$notApplied = $s.DownloadedCount + $s.NotInstalledCount + $s.UnknownCount
$failed = $s.FailedCount
# 「承認済み更新数」は、対象外(NotApplicable)を除外した上で、状態が取れているもの＋不明を含める
$approved = $installed + $notApplied + $failed
$rate = if ($approved -gt 0) { [math]::Round(($installed / $approved) * 100, 2) } else { 100 }
[pscustomobject]@{
"コンピューター名" = $computer.FullDomainName
"承認済み更新数" = $approved
"未適用（必要／保留）更新数" = $notApplied
"失敗した更新数" = $failed
"承認済み更新の適用率（％）" = $rate
}
}
# 出力
$dir = Split-Path -Parent $OutCsv
if (-not (Test-Path $dir)) { New-Item -ItemType Directory -Path $dir | Out-Null }
$report |
Sort-Object "承認済み更新の適用率（％）","コンピューター名" |
Export-Csv -Path $OutCsv -NoTypeInformation -Encoding UTF8
$report | Format-Table -AutoSize
Write-Host "Saved: $OutCsv"
このスクリプトの設計ポイントは次のとおりです。
- UpdateScope を「承認済み（LatestRevisionApproved）」に絞ることで、未承認更新を分母に入れない
- ApprovedComputerTargetGroups を使い、在宅勤務グループに対して承認された更新だけを対象にする
- GetSummariesPerComputerTarget で端末別サマリ（Installed/NotInstalled/Failed/Unknown…）を取得して集計する
月次運用に落とす：タスクスケジューラで定期実行する
「毎月レポートを出す」のが目的なら、実行手順を人手から外すのが効果的です。タスクスケジューラで以下のように登録します。
- 実行プログラム：
powershell.exe - 引数例：
-NoProfile -ExecutionPolicy Bypass -File C:\Scripts\WSUS_RemoteWork_Compliance.ps1 -WsusServer WSUS01 -Port 8530 -OutCsv C:\Reports\WSUS_RemoteWork_Compliance_$(Get-Date -Format yyyyMM).csv - 実行タイミング：月末・月初など（社内の締めに合わせる）
- 注意：レポートの数値は「端末が WSUS に状態報告した時点の情報」なので、締め日の直前に在宅端末が VPN 接続しているかが品質に直結
SQL（SUSDB）を直接叩く前に知っておきたいこと
「DB に対して SQL を書けば自由に出せそう」と考えがちですが、WSUS の DB 直参照は、運用・保守・将来更改の観点でリスクが増えます。API で取れる範囲（サマリや一覧）で要件を満たせるなら、まずは PowerShell/WSUS API をおすすめします。
課題：在宅勤務端末が VPN 経由だと「自動同期されず、手動対応が頻発する」
在宅勤務端末でよく起きるのは、「GPO で日次の検出を設定したはずなのに、VPN 接続していてもスキャンしない／ダウンロードしない」「結果として IT が都度手動適用する羽目になる」という状態です。ここは“WSUS の問題”というより、端末のオンライン時間と、検出・インストールのタイミング設計が噛み合っていないケースが大半です。
まず疑うべき：到達性とポート、DNS、証明書
WSUS クライアントは WSUS サーバーへ到達できないと始まりません。特に VPN では split tunnel（分割トンネル）や社内 DNS の参照可否で、WSUS の URL に届かないケースが多いです。クライアントが WSUS へアウトバウンドで 8530/8531（既定）に到達できるか、まず確認します。
| 症状 | チェックポイント | すぐできる確認例 |
|---|---|---|
| VPN なのに検出しない | WSUS 名解決・ルーティング | nslookup wsus.example.local、ping（許可されていれば） |
| メタデータは取れるが DL しない | 「更新ファイルの取得先」がブロックされていないか | 後述の「Microsoft Update から取得」設計の場合は外部通信が必要 |
| HTTPS 化したらつながらない | クライアントが WSUS の証明書を信頼しているか | WSUS の TLS/SSL 証明書を端末の信頼済みに配布できているか |
GPO 見直しの王道：検出頻度を“在宅の接続実態”に寄せる
在宅端末は「いつ VPN に入るか」が人によってバラバラです。検出頻度がデフォルトのままだと、せっかく VPN に入っても次のスキャンが回ってこず、“たまたま手動で回したら見つかった”が頻発します。
GPO の「Automatic Updates detection frequency（検出頻度）」は、チェック間隔（時間）を指定できます。デフォルトは 22 時間で、実際の待ち時間は指定値の 80〜100% の範囲になる、とされています（例：20 時間指定なら 16〜20 時間）。なお、この設定が効くには「Specify intranet Microsoft update service location」が有効である必要があります。
在宅端末が「平日は毎朝 VPN 接続する」なら 6〜8 時間、「週に数回だけ VPN」なら 4 時間など、現実に合わせて短くするほど“当たり”を増やせます。短くしすぎると WSUS・回線負荷が上がるため、在宅勤務グループだけ別 GPO にするのが実務的です。
「Microsoft Update から直接ダウンロード」設計にする場合の注意
後述のとおり、WSUS を「承認は WSUS、更新ファイルは Microsoft Update」設計にすると、クライアントは外部の更新サービスへもアクセスすることになります。ここで GPO の「Do not connect to any Windows Update Internet locations」を有効にしていると、外部への接続が抑止され、意図どおりにダウンロードできなくなる可能性があります。
VPN 前提で安定させる設計：外部到達できる WSUS（SSL）を検討する
「在宅端末は VPN に入る時間が短い」「VPN 帯域が細い」「接続が不安定」という環境では、そもそも WSUS への到達性を VPN に依存させない設計が効く場合があります。WSUS の既定ポートは 8530/8531 で、HTTPS/TLS を前提にするなら 8531 を用いる構成が一般的です。
ただし、WSUS を外部到達にするのはセキュリティ上の影響が大きいので、最低限次を守ってください。
- HTTPS（TLS）を必須にし、クライアントへ証明書の信頼配布を行う
- 公開範囲を絞る（IP 制限、WAF/リバースプロキシ、DMZ 配置など）
- 「端末が WSUS に状態報告できること」を優先しつつ、更新ファイルの配信経路は後述の設計で最適化する
課題：「承認は WSUS でやりたいが、更新ファイルはクライアントがインターネットから落としたい」
できること：承認は WSUS、更新ファイルの取得は Microsoft Update
WSUS には、更新ファイルを WSUS サーバーに保存するのではなく、クライアントがインターネット（Microsoft Update）から更新ファイルを取得する前提の構成があります。WSUS コンソールの「Update Files and Languages」や「Synchronization Options（Advanced）」で、更新ファイルを WSUS に保存するか、クライアントがインターネットから取得するかを選べます。
この構成にすると、WSUS は承認（どの更新を適用させるかの制御）を担い、クライアントはダウンロード（更新ファイル本体）を Microsoft 側から行う、という役割分担になります。さらに、クライアント側の GPO で「代替ダウンロード サーバー（alternate download server）」を設定している場合、これが埋まっていると Microsoft からダウンロードできないことがあるため、空にする必要がある、という注意点も知られています。加えて、クライアントが承認情報を受け取るために WSUS 自体には到達できる必要があります（VPN など）。
ただし重要：この「更新ファイルを WSUS に保存しない」設定は “グループ別に切り替え”できない
更新ファイルの保存先（WSUS に保存する／Microsoft Update から取得する）は、WSUS の「Options」配下で決めるサーバー設定です。ドキュメント上も「Update Files」セクションで保存先を選ぶ流れになっており、ターゲットグループ単位で切り替える仕組みとしては提供されていません。
そのため、次のような要望は 1 台の WSUS だけでは満たしにくいです。
- 在宅勤務グループ：更新ファイルは Microsoft Update から直接ダウンロード
- 社内グループ：更新ファイルは WSUS（社内）からダウンロード
分けたい場合の現実解：WSUS サーバーを分ける（2 台構成）
グループごとに「取得元」を分けたいなら、現実的にはWSUS サーバーを分けて、クライアントが向く WSUS を分ける設計になります。考え方としては次のイメージです。
| 方式 | 在宅端末の更新ファイル | 社内端末の更新ファイル | 運用のポイント |
|---|---|---|---|
| WSUS 1台（単一設定） | 同じ | 同じ | サーバー設定は共通のため、グループで分岐できない |
| WSUS 2台（役割分離） | Microsoft Update | WSUS ローカル | GPO/OU で WSUS の接続先（WUServer）を分ける。承認運用は統一する工夫が必要 |
WSUS を複数台にする場合、承認作業をどこで行うか（上流・下流、レプリカ、同期の方針）を最初に決めないと、二重管理になって逆に負担が増えます。「承認は 1 箇所で完結させ、在宅側は配信経路だけ変える」という設計思想で固めるのがコツです。
帯域が不安なら、設計を“二段階”で考えると失敗しにくい
在宅勤務の更新配信で詰まりやすいのは、ひとつの施策で全部を解決しようとすることです。次の二段階に分解して設計すると、判断が明確になります。
- 制御（承認・延期・適用タイミング）：WSUS（+ GPO）でどこまで統制するか
- 配信（ダウンロード経路と回線負荷）：WSUS から配るのか、Microsoft Update から取らせるのか
「制御は WSUS で続けたいが、VPN 帯域が厳しい」という状況なら、まずは配信経路だけ Microsoft Update に寄せるのが効果的です。そのうえで、社内端末と在宅端末で要件が分かれるなら、WSUS 分離（または別方式への移行）を検討すると、後戻りしづらい“痛い作り込み”を避けられます。
まとめ：在宅勤務×WSUS の悩みは「レポート」「到達性」「配信経路」を切り分ける
- グループ別の適用率レポートは、WSUS 標準だけで“要件どおりの体裁”を自動生成するのが難しいため、標準レポート＋加工か、WSUS API + PowerShell で自作が現実的
- VPN 経由で同期されない問題は、到達性（DNS/ポート/SSL）に加え、検出頻度と端末のオンライン時間のミスマッチが原因になりやすい。検出頻度は GPO で寄せられる
- 「承認は WSUS、ダウンロードは Microsoft Update」は可能だが、更新ファイル保存先の設定はサーバー単位であり、グループ別に切り替えるならWSUS 分離が現実解になりやすい
最後に、在宅勤務端末は“更新が当たらない”よりも、“更新状況が見えない（Unknown）”が先に問題化します。レポート自動化は単なる作業削減ではなく、未報告端末を早期にあぶり出す監視として設計すると、運用品質が一段上がります。
コメント