Windows 10 に MEMCM（ConfigMgr / SCCM）クライアントだけを導入した環境で、ドメイン GPO の「社内 Microsoft 更新サービスの場所を指定する（WSUS サーバー指定）」を設定したのに、いつの間にか SUP 用 WSUS の値へ戻っているように見える――この現象は“二重管理”が原因で起きがちです。仕組みを整理し、最短で安定させる手順をまとめます。
現象を正しく理解するための前提（WSUS / SUP / Windows Update Agent）
まず、同じ「更新」でも関わるコンポーネントが複数あり、設定の入口が混ざると誤解が生まれます。今回の相談で登場する主役は次の3つです。
| 要素 | 役割 | ここで混乱しやすい点 |
|---|---|---|
| WSUS | 社内向けの Microsoft 更新配信サーバー。クライアントは Windows Update Agent（WUA）で WSUS を参照してスキャン・ダウンロードします。 | 「WSUS を指定する」といっても、実体は Windows のポリシー（レジストリ）に WUServer などを書き込むこと。 |
| SUP（Software Update Point） | MEMCM が更新管理をするための役割。内部的には WSUS を使い、MEMCM の管理下で更新メタデータを同期・配布します。 | 「SUP 用の WSUS」と「純粋な WSUS 運用」を同じ端末に同時適用すると、端末側の参照先がぶつかります。 |
| Windows Update Agent（WUA） | Windows クライアントの更新エンジン。どの更新源を参照するか、GPO/ローカルポリシー/MDM 等の設定に従って動きます。 | WUA は最終的に「現在レジストリに入っている値」を見に行くため、書き込みタイミングで“行ったり来たり”しているように見えます。 |
結論：ドメイン GPO が“恒久的に負ける”ことはない（見えているのはタイミング差）
結論から言うと、SCCM / MEMCM クライアントがドメイン GPO を「破って」恒久的に上書きする、という理解は誤解です。ドメイン GPO はクライアントのポリシー適用エンジンによって定期的に再適用されます。
ただし、ここが重要です。
- ドメイン GPO が「優先」でも、レジストリの値は“最後に書いたプロセス”の値が一時的に見えることがあります。
- MEMCM クライアントが更新管理（Software Updates）を有効にしている場合、WUA 向けの設定をローカルポリシーとして書き込むことがあります。
- 結果として、GPO 更新（例：90分周期＋ランダム）と MEMCM ポリシー更新（例：60分周期、手動トリガー）で、値が交互に見える「ping-pong」に陥ります。
つまり「ドメインが負けている」のではなく、設計として同じ場所（WSUS参照先）を2系統が触っているのが根本原因です。
なぜ「SCCM が WSUS の GPO を戻す」ように見えるのか（代表パターン3つ）
パターン1：GPO と MEMCM が同じ設定（WSUS参照先）を両方で触っている
GPO の「社内 Microsoft 更新サービスの場所を指定する」は、端末のポリシー領域に WSUS の URL を書き込みます。一方、MEMCM で Software Updates を有効にしていると、クライアントは SUP から「この端末はこの WSUS（SUP に紐づく WSUS）を参照せよ」という方針を受け取り、同じ領域を更新しようとします。
この状態では、次のような見え方になります。
- GPO 適用直後：
WUServerが社内 WSUS に見える - MEMCM ポリシー取得後：
WUServerが SUP 側（SUP の WSUS）に見える - 次回 GPO 更新：また社内 WSUS に戻る
画面やレジストリを見た瞬間で「奪われた」と感じやすいのはこのパターンです。さらに MEMCM 側で Group Policy conflict（グループポリシー競合） として検知され、スキャンが失敗したり、更新機能が抑止されたりします。
パターン2：GPO が “SUP 想定と違う” とき、MEMCM が更新機能を抑止している
MEMCM クライアントは「更新管理を自分が担う前提」で動いているため、端末が別の WSUS を参照する構成だと整合性が崩れます。このとき、クライアントは無理にドメイン GPO を破壊するのではなく、Software Updates エージェントの動作を止める（無効化・スキャンしない）という判断をすることがあります。
結果として、
- コンソールでは更新が適用されない／状態が上がらない
- 端末側では「設定が勝手に変わる」「更新が止まる」ように見える
といった症状になり、「SCCM が奪っている」と誤認されやすくなります。真偽は後述の WUAHandler.log を見るのが最短です。
パターン3：そもそも GPO が当たっていない（OU/フィルタ/継承/ループバック）
意外に多いのが「GPO を作ったつもりでも、対象端末に適用されていない」ケースです。例えば以下の要因があります。
- 端末が想定と違う OU にいる（移動漏れ、命名違い）
- セキュリティフィルタ／WMI フィルタで除外されている
- 上位 OU の GPO が上書きしている、継承ブロックがある
- ループバック（置換/マージ）で想定外のユーザー側ポリシーが混ざっている
この場合は、MEMCM が WSUS（SUP）設定を入れるのが自然な動きなので、結果として「SCCM が変えた」に見えます。まずは gpresult/RSOP で“当たっている事実”を固めるのが鉄則です。
最初にやるべき切り分け（チェックリスト）
症状を短時間で収束させるには、「GPO が当たっているか」→「レジストリがどうなっているか」→「ログが何と言っているか」の順で確認します。おすすめのチェック項目を表にまとめます。
| 確認すること | 具体的な確認方法 | 期待値（正常の考え方） | ズレていた場合の次アクション |
|---|---|---|---|
| GPO が端末に適用されているか | gpresult /h C:\temp\gp.html rsop.msc | 「社内 Microsoft 更新サービスの場所を指定する」が“適用済み”として表示される | OU/フィルタ/継承/ループバックを再点検し、適用をまず成立させる |
| 現在の WSUS 参照先がどこか | reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /v WUServer reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /v WUStatusServer | GPO 運用なら社内 WSUS、MEMCM 運用なら SUP の WSUS を指す | “両方の値が入れ替わる”なら二重管理。方針を1本化する |
| MEMCM の更新管理が有効か | コンソール：管理（Administration）→ クライアント設定（Client Settings）→ Software Updates → Enable software updates on clients | WSUS 運用にしたい端末では「無効（No）」になっている | 対象コレクション向けにカスタム設定を作成し、Software Updates を無効化する |
| 競合が検知されているか | C:\Windows\CCM\Logs\WUAHandler.log を CMTrace で確認 | 競合がなければスキャンが継続し、エラーや“conflict”が繰り返し出ない | “Group Policy conflict” が出るなら GPO と MEMCM の二重設定を解消する |
| 端末の更新ソースが他にもあるか（MDM 等） | Intune 参加、WUfB（更新の延期）ポリシー、Windows Update for Business の設定有無を確認 | 更新ソースが一本なら挙動が単純になる | 他の管理口がある場合は、更新方針を整理し、優先順位と担当を決め直す |
レジストリで確認する「WSUS 指定」のポイント
GPO の「社内 Microsoft 更新サービスの場所を指定する」は、主に次のキーに反映されます。トラブル時は、ここが“どの値になっているか”と“いつ変わるか”が重要です。
| 場所 | 値 | 意味 | 典型例 |
|---|---|---|---|
HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate | WUServer | 更新の参照先（WSUS サーバー URL） | http://wsus01:8530 または http://sup01:8530 |
HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate | WUStatusServer | 状態送信先（通常は WUServer と同一） | http://wsus01:8530 |
HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU | UseWUServer | WSUS を使うか（1=使う / 0=使わない） | 社内 WSUS 運用なら 1 |
HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU | AUOptions | 自動更新の動作（通知のみ/自動DL/自動インストール等） | 運用ポリシーにより異なる |
ここでの注意点は、「値がどちらを向いているか」だけで断定しないことです。次回の GPO 更新や MEMCM ポリシー取得で変わるなら、二重管理が成立しています。安定させるには“どちらか一方だけが触る”状態に戻す必要があります。
ログで事実確認する（最優先は WUAHandler.log）
「SCCM が書き換えた気がする」「GPO が勝っているはずなのに」などの議論は、ログを見れば数分で決着します。特に WSUS/GPO/Software Updates の絡みでは WUAHandler.log が核心です。
| ログ | 場所 | 分かること | 探すキーワード例 |
|---|---|---|---|
| WUAHandler.log | C:\Windows\CCM\Logs\WUAHandler.log | WUA の設定検知、WSUS 参照先、競合判定、スキャン開始/失敗の理由 | Group Policy, WUServer, conflict, disable, Scan |
| PolicyAgent.log | C:\Windows\CCM\Logs\PolicyAgent.log | クライアント設定（Software Updates など）がどの優先度で適用されたか | Client Settings, Software Updates |
| LocationServices.log | C:\Windows\CCM\Logs\LocationServices.log | 端末がどの SUP を参照するか（境界/境界グループの影響を含む） | SUP, WSUS, Location |
| ScanAgent.log | C:\Windows\CCM\Logs\ScanAgent.log | ソフトウェア更新スキャンの要求と結果（WUA への呼び出し状況） | Scan, Request, Result |
| UpdatesDeployment.log | C:\Windows\CCM\Logs\UpdatesDeployment.log | 配布・適用判定（“更新が来ない”の切り分け） | Assignment, CI, Deadline |
特に WUAHandler.log では、「GPO を検出した」「想定外の WSUS なので競合」「このため更新を無効化」といった意思決定の痕跡が残ります。ここを押さえると、原因が“勘”ではなく“事実”になります。
最短の解決方針：WSUS の指定は「GPO か MEMCM のどちらか一方」に統一する
実務上、安定運用できる設計は次の2択です。端末が参照する WSUS を 1つに決め、その設定口も 1つにします。併用（同一端末に GPO と MEMCM の両方）は、意図が明確でない限り避けるのが安全です。
| 方針 | 推奨シーン | GPO の WSUS 指定 | MEMCM（Software Updates） | メリット | 注意点 |
|---|---|---|---|---|---|
| 方針A：WSUS を GPO で強制 | 更新は WSUS で完結させたい／MEMCM は配布だけで使いたい | 有効（社内 WSUS を指定） | 対象端末では無効化 | 構成が単純、WSUS のみで運用しやすい | MEMCM の更新配布・準拠率レポートは使いづらくなる |
| 方針B：更新は MEMCM に統一 | 更新の配布・期限・準拠率を MEMCM で管理したい | 無効/未構成（WSUS 指定は外す） | 有効（SUP 参照） | 更新の見える化、段階展開、レポートが強い | SUP/WSUS の健全性、境界設計、同期運用が必要 |
| 方針C：端末群で分ける（混在はするが端末単位で一本化） | 部門・拠点で運用が異なる／段階的に移行中 | 端末A群のみ有効、端末B群は外す | 端末B群のみ有効、端末A群は無効 | 移行期間に現実的 | 適用範囲が曖昧だと同一端末で競合しやすい |
解決策A：WSUS だけで運用したい（MEMCM の Software Updates を止める）
「GPO で WSUS を強制し、更新は WSUS/Windows の仕組みで回す」方針なら、MEMCM 側は Software Updates を無効にします。ポイントは“SUP は存在していても、対象端末に効かせない”ことです。
手順（実務で事故が少ない順）
- 対象端末をコレクションで明確化
「WSUS 管理にしたい端末」だけのデバイスコレクションを作ります。曖昧なまま設定変更すると、更新管理が一時的に外れて監査に響くことがあります。 - カスタム クライアント設定を作成し、Software Updates を無効化
コンソールで新規のクライアント設定を作り、Software Updates → Enable software updates on clients = No にします。作成した設定を 1 のコレクションへ展開します。
既に複数のクライアント設定がある場合は、優先度（Priority）に注意してください。一般に「数値が小さいほど優先度が高い」ため、意図した設定が勝つよう調整します。 - （可能なら）対象端末への更新展開を停止/整理
MEMCM の更新配布（Software Update Group の展開）が残っていると、クライアントは受け取っても実行できず、エラーや不要なアラートが増えます。移行・併用の方針がないなら、展開範囲を分けます。 - クライアント側でポリシー更新 → GPO 更新を実施
クライアントで「Machine Policy Retrieval & Evaluation Cycle」を実行し、その後にgpupdate /forceを実行します。
さらに挙動が安定しない場合は、wuauserv（Windows Update）サービスの再起動で“読み直し”を促すと切り分けが早いです。 - 確認（レジストリ & ログ）
WUServerが社内 WSUS を指して固定されること、WUAHandler.log に競合の繰り返しが出ないことを確認します。
この方針の“落とし穴”
- 「SUP を入れているから MEMCM で更新管理しているはず」という誤解が起きやすい（役割が存在することと、端末が使うことは別です）。
- WSUS 側のターゲット グループ、承認フロー、期限運用を決め直す必要がある（MEMCM の段階展開に慣れているとギャップが出ます）。
解決策B：更新は MEMCM に統一したい（GPO の WSUS 指定を外す）
更新の配布計画・期限・準拠率を MEMCM で管理したいなら、WSUS 参照先の指定は MEMCM に一本化します。GPO の WSUS 指定が残っていると、競合が再発しやすいので、ここは割り切りが必要です。
手順（端末側が迷わない構成にする）
- GPO の「社内 Microsoft 更新サービスの場所を指定する」を未構成（または無効）へ
端末が参照する WSUS は MEMCM が管理します。GPO は触らないのが最も安全です。 - MEMCM のクライアント設定で Software Updates を有効化
Enable software updates on clients = Yes を確認します。複数のクライアント設定がある場合は優先度を必ず確認します。 - SUP/WSUS の到達性と証明書（SSL の場合）を確認
クライアントが SUP の WSUS（通常は 8530/8531）へ到達できないと、スキャンエラーが出ます。境界グループやプロキシ構成も含めて確認します。 - クライアントでスキャンを実行し、WUAHandler.log で成功を確認
コントロールパネルの「Configuration Manager」から Software Updates Scan Cycle を実行し、スキャンが完走するか確認します。
この方針では、レジストリの WUServer が SUP 側の WSUS を指すのは正常です。ここを「社内 WSUS に戻したい」と考え始めると、再び二重管理に戻ります。
解決策C：どうしても混在させたい場合（端末単位で一本化し、境界を明確にする）
現実には「一部の端末だけ WSUS で回したい」「移行期間だけ混在する」こともあります。その場合のコツは、同一端末に GPO と MEMCM の両方を当てないことです。混在させるなら“端末群を分けて”一本化します。
分け方の例（おすすめ順）
| 分離方法 | やり方 | メリット | 注意点 |
|---|---|---|---|
| OU で分ける | WSUS 運用端末は OU-A、MEMCM 運用端末は OU-B に分離し、GPO のリンクを分ける | 最も分かりやすく、監査・運用が楽 | OU 移動漏れがあると即競合。運用ルールが必須 |
| セキュリティグループで分ける | GPO のセキュリティフィルタで「WSUS対象」グループだけ適用 | OU を変えられない環境でも使える | グループ管理が煩雑になりやすい |
| コレクション＋クライアント設定で分ける | MEMCM 側はコレクションごとに Software Updates を有効/無効化 | MEMCM の範囲管理が得意な場合に有効 | GPO の適用範囲も同時に分けないと競合が残る |
移行期間の混在は可能ですが、境界が曖昧だと「いつの間にか両方が当たっていた」が起きます。トラブルが増えるほど、移行が遅れます。“1台に1ルール”を徹底するのが結果的に最短です。
よくある質問（現場のつまずきポイント）
レジストリを見ると SUP の値になっている。やはり SCCM が GPO を上書きした？
“今その瞬間のレジストリ値”だけを見るとそう見えます。ただし、次の2点を確認してください。
- gpresult で GPO が適用済みか（適用されていなければ当然 SUP の値になり得ます）
- 一定時間後に値が戻る/また変わるか（変動するなら二重管理のサインです）
恒久的に固定したいなら、GPO と MEMCM のどちらか一方に一本化します。
「Group policy conflict」が出た。放置すると何が起きる？
放置すると、更新スキャンが失敗し続けたり、準拠率が上がらなかったり、更新が適用されない端末が増えます。さらに厄介なのは「端末によって挙動が違う」状態になり、原因が追いにくくなることです。競合が見えた時点で“設計の二重化”を疑い、範囲と方針を整理するのが近道です。
WSUS の GPO はそのまま、MEMCM の更新も使いたい（併用したい）
同一端末での併用は、意図が明確でない限りおすすめしません。どうしても併用が必要なら、少なくとも「端末群で分ける」「どの端末がどちらの更新ソースを使うか」を監査可能な形にします。併用というより“混在”に設計を変えるイメージです。
実践的なトラブルシューティング例（短時間で決め切る）
最後に、現場でよくある流れを例としてまとめます。
例：GPO で WSUS を指定したのに、翌日には SUP に戻って見える
- 観測：
WUServerがhttp://wsus01:8530→ しばらくするとhttp://sup01:8530に変化 - 切り分け：
- gpresult で GPO は適用済み
- PolicyAgent.log で Software Updates 有効のクライアント設定が適用されている
- WUAHandler.log に conflict を示す記録が繰り返し出ている
- 判断：同一端末で GPO と MEMCM が WSUS 参照先を二重管理している
- 対処：WSUS 運用に統一 → 対象コレクションに「Software Updates 無効」のクライアント設定を適用
- 結果：以後、
WUServerは wsus01 で固定、競合ログも停止
このように、事実確認の軸を「GPO」「レジストリ」「ログ」に置くと、感覚的な議論にならずに決着できます。
まとめ：安定させる鍵は“二重管理をなくす”こと
- 「SCCM がドメイン GPO を恒久的に上書きする」というより、GPO と MEMCM が同じ設定を触っていることが原因で“上書きに見える”ことが多いです。
- 最短解は、WSUS の参照先指定を GPO か MEMCM のどちらか一方に統一することです。
- 切り分けは gpresult / RSOP、レジストリ（
WUServerなど）、そして WUAHandler.log が要点です。
更新は止めるとすぐ監査・セキュリティに影響が出ます。焦って対処を増やすより、まずは“どの仕組みで更新を管理するか”を決め、設定口を一本化してからログで確認するのが、結局いちばん早く安定します。
コメント