MENU

ワークグループ環境でWSUSを使いWindows Updateを自動配布する方法（非ドメイン10台対応）

Windows Server

ドメインに参加していないワークグループ端末でも、WSUS（Windows Server Update Services）を使って複数台へWindows Updateを自動配布できます。ポイントは「各端末が更新の参照先をMicrosoftではなくWSUSに向ける設定」を入れること。この記事では10台規模を想定し、現場で迷いがちな設定・配布方法・つまずき対策までまとめて解説します。

ITtripTOOLS
その「面倒」、無料で解決。 ITtripがつくる、6つの道具。 無料ツール一覧へ すべて無料・追加課金なし
先頭0を守るCSV編集こわさないCSV PDFに直接書き込みかけるPDF 写真＋説明をPDFに写レポ スマホ⇄PCで共有コピペ便 · 文章・写真 みんなの日程を調整日程Fit 匿名質問・投票を集めるKOEQ
目次

結論：ワークグループ環境でも同じWSUSサーバーで自動更新は可能

WSUSは「端末がどこから更新を取りに行くか（更新元のURL）」を端末側で指定できれば動作します。つまり、ドメイン参加が必須ではありません。

ただしドメイン環境のようにGPO（グループポリシー）で一括配布できないため、ワークグループ環境では以下が必須になります。

  • 各端末へ「WSUS参照設定」を入れる（ローカルGPO、レジストリ、スクリプト配布など）
  • WSUSへ到達できるネットワーク（名前解決・ポート・証明書など）を整える
  • 運用面（テスト→本番の段階配布、再起動制御）を設計する

まず押さえる：WSUSの動作イメージ（ドメイン不要な理由）

WSUSで更新が配布される流れはシンプルです。

  • WSUSサーバーがMicrosoft Updateから更新メタデータを同期
  • 管理者がWSUSコンソールで「承認（Approve）」
  • クライアント端末が指定されたWSUS URLへ定期的に問い合わせ
  • 端末は承認済み更新をダウンロードして、指定したタイミングでインストール

端末がWSUSへ名乗る際の識別は基本的に端末のGUID（SusClientId）で行われます。ADのユーザー/コンピューターアカウントに依存しないため、ワークグループでも運用できます。

WSUSサーバー側で事前にやっておくこと（チェックリスト）

ワークグループ端末側の設定ばかり注目されがちですが、WSUS側の準備が不十分だと「端末が見えない」「承認したのに降ってこない」といったトラブルに直結します。最初に以下を固めておくと安定します。

項目推奨・確認ポイント現場メモ
WSUSのURLHTTP:8530 または HTTPS:8531端末側設定にそのまま書くので、後から変えにくい（先に決める）
名前解決端末からWSUS名が引けるDNSが弱い環境ならhosts固定も可。ただし運用負担増
ファイアウォール8530/8531 を端末→WSUSで許可途中にFW/UTMがある場合は経路全体で確認
同期設定製品/分類/言語を絞る闇雲に全部同期すると容量・性能・管理工数が崩壊しやすい
コンピューターグループテスト用/本番用/サーバー用など10台でも段階配布（先行2台→残り8台）を強く推奨
承認ルール自動承認は慎重にまずは手動承認＋テスト運用で傾向を掴む

WSUSのコンピューターグループ設計（10台想定のおすすめ）

  • Pilot（先行適用）：2台（影響が少ない端末、もしくは管理者が使う端末）
  • Production（本番）：残り8台
  • Servers（サーバー）：もし同一WSUSでサーバーも管理するなら分離（再起動ポリシーが違うため）

この分け方にしておくと、更新トラブルが起きた時に被害を最小化できます。「10台しかないから一括でいい」とやると、ある月の更新で全台が同時に不調になり復旧が大変になります。

ワークグループ端末側で必須：WSUSへ向ける設定

ドメインGPOが使えないため、端末ごとにWSUS参照設定を入れます。方法は大きく2つです。

方法向いているケースメリットデメリット
方法A：ローカルグループポリシー（gpedit.msc）台数が少ない／まず1台だけ試したいGUIで分かりやすい、設定ミスが減る台数が増えると手作業が重い
方法B：レジストリ設定（スクリプト配布）10台以上／同じ設定を一気に入れたい一括適用しやすい、再現性が高い権限や配布経路の設計が必要

方法A：ローカルグループポリシーで設定する（端末ごと）

まずは1台で検証するなら、この方法が確実です。

設定手順

  1. 対象端末で gpedit.msc（ローカル グループポリシー エディター）を起動
  2. コンピューターの構成 → 管理用テンプレート → Windows コンポーネント → Windows Update を開く
  3. 以下の項目を設定

最低限入れたい設定

  • イントラネットの Microsoft 更新サービスの場所を指定する
    有効 → 以下を設定
    • 更新サービス：http://WSUS-SRV:8530（例）
    • 統計サーバー：http://WSUS-SRV:8530（例）
    HTTPの場合は8530、HTTPSの場合は8531が一般的です。URLは端末側に固定されるので、サーバー名（FQDN）を含めて最初から決め打ちにするのが運用上ラクです。
  • 自動更新を構成する
    有効 → 推奨は「自動ダウンロードしてスケジュール インストール」
    端末の利用時間帯に合わせてインストール時刻を設定します。業務端末なら「昼に勝手に再起動」しないよう調整が重要です。

運用を安定させる追加設定（おすすめ）

  • 自動更新のスケジュールされたインストール時刻に自動再起動しない（ログオン中ユーザーがいる場合の再起動抑止）
  • Windows Update のインターネット ロケーションに接続しない（WSUS以外に取りに行かないようにする）
  • クライアント側ターゲット（WSUSのグループへ自動振り分けしたい場合）

設定反映の確認

設定後、管理者権限のコマンドプロンプトで以下を実行して反映を促します。

gpupdate /force

方法B：レジストリで設定する（スクリプト配布向き）

10台規模なら、最終的にこの方法が最も現実的です。端末に同じ設定を入れたい時、レジストリをスクリプトで一括適用できると「作業の再現性」と「人為ミスの削減」が大きく効きます。

WSUS参照に必要な主要レジストリ一覧

パス値名型例意味
HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdateWUServerREG_SZhttp://WSUS-SRV:8530更新取得先（WSUS）
HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdateWUStatusServerREG_SZhttp://WSUS-SRV:8530状態報告先（通常は同じWSUS）
HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AUUseWUServerREG_DWORD1WSUSを使うか

自動更新の動作（AUOptions）も合わせて制御する

「WSUSを参照する」だけだと、端末側の更新動作がバラつきます。運用の想定があるなら、インストール方式も揃えると管理が楽になります。

AUOptions意味（代表例）運用の向き不向き
2ダウンロードとインストールを通知手動運用寄り。管理者が操作する前提
3自動ダウンロード、インストールは通知端末利用者が最終判断する環境
4自動ダウンロード＆スケジュールインストールサーバー/端末を「自動適用」で揃えたい環境に最適
5ローカル管理者に設定選択を許可（環境により挙動差あり）統制が弱くなりやすいので慎重に

バッチ（.bat）例：WSUSをHTTP(8530)で指定し、自動インストールにする

まずは「最小構成＋自動インストール」のテンプレです。必要に応じて時刻や曜日を追加します。

:: ===== WSUS クライアント設定（テンプレ）=====
:: 管理者として実行してください

set WSUS_URL=http://WSUS-SRV:8530

:: WSUS を参照
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /v WUServer /t REG_SZ /d "%WSUS_URL%" /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /v WUStatusServer /t REG_SZ /d "%WSUS_URL%" /f

:: WSUS を使う
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" /v UseWUServer /t REG_DWORD /d 1 /f

:: 自動更新：4=自動ダウンロード＆スケジュールインストール
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" /v AUOptions /t REG_DWORD /d 4 /f

:: 毎日 3:00 にインストール（0=毎日）
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" /v ScheduledInstallDay /t REG_DWORD /d 0 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" /v ScheduledInstallTime /t REG_DWORD /d 3 /f

:: ログオン中ユーザーがいる場合に自動再起動しない（運用で好みが分かれる）
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" /v NoAutoRebootWithLoggedOnUsers /t REG_DWORD /d 1 /f

:: インターネット側へ取りに行かない（WSUS統制を強める）
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /v DoNotConnectToWindowsUpdateInternetLocations /t REG_DWORD /d 1 /f

:: サービス再起動（反映促進）
net stop wuauserv
net start wuauserv

echo Done.

WSUSのグループ機能を使う場合（クライアント側ターゲット）

端末が勝手に「Pilot」「Production」などのグループへ入るようにしたい場合、端末から「所属グループ名」を名乗らせます。

:: 例：Production グループへ自動所属
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /v TargetGroupEnabled /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /v TargetGroup /t REG_SZ /d "Production" /f

WSUSコンソール側でも「クライアント側ターゲットを使う」前提で運用を揃える必要があります。混在すると、意図しないグループへ入る/入らないが起きやすいので、最初に方針を決めてください。

PowerShell例：パラメータ化してミスを減らす（おすすめ）

複数台に配布するなら、PowerShellで「WSUS URL」「グループ名」「インストール時刻」を変数化しておくと事故が減ります。

param(
  [string]$WsusUrl = "http://WSUS-SRV:8530",
  [string]$TargetGroup = "",
  [int]$InstallHour = 3
)

$WUPath  = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate"
$AUPath  = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU"

New-Item -Path $WUPath -Force | Out-Null
New-Item -Path $AUPath -Force | Out-Null

Set-ItemProperty -Path $WUPath -Name WUServer -Type String -Value $WsusUrl
Set-ItemProperty -Path $WUPath -Name WUStatusServer -Type String -Value $WsusUrl
Set-ItemProperty -Path $AUPath -Name UseWUServer -Type DWord -Value 1

# 自動更新：スケジュールインストール
Set-ItemProperty -Path $AUPath -Name AUOptions -Type DWord -Value 4
Set-ItemProperty -Path $AUPath -Name ScheduledInstallDay -Type DWord -Value 0
Set-ItemProperty -Path $AUPath -Name ScheduledInstallTime -Type DWord -Value $InstallHour

# ログオン中ユーザーがいる場合の自動再起動抑止
Set-ItemProperty -Path $AUPath -Name NoAutoRebootWithLoggedOnUsers -Type DWord -Value 1

# WSUS統制を強める（必要に応じて）
Set-ItemProperty -Path $WUPath -Name DoNotConnectToWindowsUpdateInternetLocations -Type DWord -Value 1

# クライアント側ターゲット（必要な場合のみ）
if ($TargetGroup -ne "") {
  Set-ItemProperty -Path $WUPath -Name TargetGroupEnabled -Type DWord -Value 1
  Set-ItemProperty -Path $WUPath -Name TargetGroup -Type String -Value $TargetGroup
}

# サービス再起動
Stop-Service wuauserv -Force
Start-Service wuauserv

"WSUS client settings applied. WsusUrl=$WsusUrl TargetGroup=$TargetGroup InstallHour=$InstallHour"

「10台へ一括適用」する現実的なやり方

ワークグループでは「ドメインGPOで自動配布」ができない代わりに、次のどれかで横展開します。

手元USB・ファイル共有で配布（最小構成）

  • 共有フォルダにスクリプトを置く
  • 各端末で管理者として実行

台数が増えると手間ですが、最初の導入段階では最も確実です。

PowerShell Remoting（WinRM）で一括実行（少し上級だが便利）

端末側でWinRMを有効化できるなら、管理端末から一気に流せます。ワークグループの場合は認証や信頼設定が絡むため、まずは検証端末で小さく成功させるのがコツです。

  • 端末側：WinRM有効化（セキュリティ方針に合わせる）
  • 管理端末側：端末一覧に対してInvoke-Commandで実行

環境によって実装の作法が変わるため、ここでは「一括実行できる」という選択肢として押さえるに留め、基本はスクリプト配布運用で問題ありません。

設定後に必ずやる：動作確認の手順

「設定を入れたのにWSUSに端末が出てこない」問題は頻出です。以下の順番で確認すると切り分けが速いです。

端末で確認すること

  • WSUS URLが正しく入っているか（レジストリ/ポリシー）
  • WSUSへ到達できるか（名前解決・ポート）
  • Windows Updateサービス（wuauserv）が動いているか

端末から疎通確認（例：HTTP 8530）

Test-NetConnection WSUS-SRV -Port 8530

端末から更新スキャンを促す（代表例）

Windowsのバージョンや構成で挙動が変わることがありますが、現場で使われる代表例を挙げます。

  • UsoClient（比較的新しい系統）
UsoClient StartScan
UsoClient StartDownload
UsoClient StartInstall
  • wuauclt（環境によっては効くが、万能ではない）
wuauclt /detectnow
wuauclt /reportnow

実務的には「スキャンを促す」よりも、まずはWSUSへ端末が登録されるかを見て、登録されないなら通信・URL・証明書・SusClientIdを疑う方が早いです。

WSUSコンソール側で確認すること

  • WSUSの「コンピューター」に端末が出てくるか（数分〜時間差あり）
  • 端末が想定したグループに入っているか（自動振り分け設定の有無）
  • 承認済み更新が対象グループに対して「インストール承認」になっているか

つまずきポイント集（ワークグループで特に起きやすい）

WSUSに端末が表示されない

よくある原因確認ポイント対処の方向性
WSUS URLの指定ミスhttp/https、ポート、サーバー名端末のレジストリ値を見て、URLを統一
名前解決できていないping/NSLookup、hostsDNS整備 or hosts固定（小規模なら現実解）
ポート遮断Test-NetConnection8530/8531を端末→WSUSで許可
HTTPSで証明書が信頼されていないブラウザでWSUS URLにアクセス時の警告社内CA/自己署名の場合は端末へルート証明書配布
端末のSusClientIdが重複クローン展開端末で頻発SusClientIdをリセットして再登録

クローン端末で頻出：SusClientId重複をリセットする

イメージ展開（クローニング）した端末が複数あると、WSUS上で1台に上書きされて「台数が増えない」症状が出ることがあります。以下は代表的なリセット手順です（管理者権限で実行）。

net stop wuauserv

reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v SusClientId /f
reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v SusClientIdValidation /f

net start wuauserv

:: 可能ならスキャンを促す
UsoClient StartScan

この作業後、WSUS側に新しい端末として登録されるまで時間差が出ることがあります。まずは通信とURLが合っているかを優先して確認してください。

承認したのに更新が入らない

  • 端末が対象グループに入っていない（Pilotだけ承認していた、など）
  • 更新の分類/製品が同期対象から外れている（WSUS側設定）
  • 端末側のインストールスケジュールが合っていない（夜間にしか入らない設定）
  • 再起動待ちが溜まっている（更新の適用が止まって見える）

10台規模で失敗しない運用例（段階配布と再起動設計）

「自動適用したい」という要望は多いですが、実際の事故は「業務時間中に再起動」「特定更新でアプリ不具合」が原因になりがちです。小規模でも段階配布と再起動設計を入れておくと、更新運用が“回る”ようになります。

おすすめの段階配布フロー

タイミングPilot（2台）Production（8台）狙い
更新公開直後承認（インストール）未承認影響確認を先行2台で吸収
数日〜1週間後継続適用承認（インストール）問題が出なければ本番展開
トラブル発生時承認取り消し/一時停止承認しない被害拡大を防ぐ

再起動で揉めないための考え方

  • 業務端末：ログオン中の自動再起動を抑止し、メンテ時間に再起動する運用へ寄せる
  • サーバー：端末と同じポリシーにしない（業務影響と復旧手順が別物）
  • 「インストールは自動」でも「再起動は管理者が判断」など、線引きを決めると揉めにくい

HTTPS（8531）を使う場合の注意点（ワークグループで詰まりやすい）

HTTPSはセキュアですが、ワークグループでは証明書の配布経路が弱くなりがちです。以下を押さえてください。

  • 端末側がWSUSのサーバー証明書を信頼している必要がある（社内CA/自己署名ならルート証明書の配布が必須）
  • 証明書のCN/SANは端末がアクセスする名前（FQDNなど）と一致させる
  • URL指定は https://WSUS-SRV:8531 のように統一する

10台規模で「まず動かす」優先ならHTTP(8530)で立ち上げ、運用が固まってからHTTPSへ移行する方が安全なケースもあります（要件次第）。

小規模でもやっておくと効く：WSUS運用のメンテナンス

WSUSは放置すると、更新データや不要メタデータが増えて同期が遅くなったり、コンソール操作が重くなったりします。小規模でも最低限のメンテを回すのがおすすめです。

  • 不要/置換済み更新（Superseded）の整理
  • WSUSのクリーンアップウィザードの定期実行
  • WSUSのコンテンツ保存先の空き容量監視
  • 承認のルール（誰が、いつ、どのグループへ）を簡単に文書化

よくある質問（現場目線）

ワークグループ端末でも「自動更新」まで本当にできる？

できます。端末がWSUSへ向く設定（ローカルGPOまたはレジストリ）を入れ、AUOptionsなどで自動インストール方式を統一すれば、ドメイン環境に近い自動更新運用が可能です。

10台なら方法A（手動設定）でもいい？

初期検証は方法Aが分かりやすいですが、運用で設定変更や端末入替が起きると手作業がボトルネックになります。最終的には方法B（スクリプト化）に寄せた方が、後々ラクになります。

サーバーとクライアントを同じWSUSで管理して問題ない？

同じWSUSで管理して問題ありません。ただし、グループは必ず分けるのがおすすめです。承認タイミングや再起動設計が違うため、同一グループ運用は事故を呼びます。

まとめ：ワークグループでもWSUS自動配布は「端末設定の配布設計」がすべて

ワークグループ環境（非ドメイン参加）でも、同じWSUSサーバーを使って複数台へWindows Updateを自動適用できます。成功の鍵は、端末側へ「WSUS参照設定」と「自動更新ポリシー」を確実に入れ、段階配布と再起動設計で運用事故を防ぐことです。10台規模なら、まず1台をローカルGPOで検証し、固まったらレジストリ/PowerShellで横展開する流れが最短で安定します。

Windows Server
wsus PowerShell レジストリ Windows Update ワークグループ

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次