LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

WSUSとは？Microsoftが2024年9月に発表した非推奨化の内容

WSUS（Windows Server Update Services）とは、社内のWindows端末やサーバーへ更新プログラムを配信・管理するMicrosoft製の無料機能です。2024年9月20日、Microsoftは公式ブログでWSUSの非推奨(deprecated)化を発表し、新機能の追加は停止する一方、既存機能や配信は当面継続すると説明しました^*1。

WSUSは、少なくとも1台のサーバーがMicrosoft Updateへ接続し、社内の他端末やサーバーへ更新情報を配信する仕組みです^*2。Windows PowerShellによる自動化やSHA-256によるハッシュ検証にも対応しており、長年にわたり社内ネットワークの更新配信を集中管理する役割を担ってきました^*2。

Microsoftは公式ブログで「WSUSの新しい機能については投資を行わず、新規の機能要望も受け付けない」と明言しています^*1。あわせて、既存の機能や配信済みコンテンツのサポートは継続する方針も示しました^*1。この発表は、Windows Server 2025を含む在庫バージョンからWSUSを削除する計画がない一方で、開発体制の重心をクラウド側の更新管理へ移す方針転換と言えるでしょう。

非推奨と廃止の違い－既存機能は当面維持され新機能は追加されない

公式ドキュメントが定義する「非推奨」の意味

Microsoft Learnは「非推奨(deprecation)」について、「機能・機能性・サービスが積極的な開発の対象でなくなった状態を指し、将来のリリースで削除される可能性がある」と定義しています^*3。同時に「非推奨となったコンポーネントも引き続きWindows Serverに含まれ、本番環境での利用がサポートされ、製品ライフサイクルに従ってセキュリティ・品質更新を受け取る」とも説明されています^*3。

この定義に沿うと、非推奨は即時のサービス終了を意味しません。WSUSのオーバービュー記事でも「WSUSは非推奨であり新機能は追加されないが、本番環境での利用は引き続きサポートされ、製品ライフサイクルに従ったセキュリティ・品質更新を受け取る」と明記されています^*2。放置してよいという結論にはならないものの、猶予期間があるという理解が正確です。

WSUSが依存するコンポーネントも順次非推奨に

Windows Server 2025では、AD FS・IPAM・RD Connection Broker・WSUSなど複数の役割が利用するWindows Internal Database（WID。SQL Serverの簡易版として複数の役割で共有利用されるデータベース基盤）も非推奨と位置づけられ、将来のリリースで削除される予定です^*3。WSUS本体だけでなく、その基盤コンポーネントも段階的に開発対象から外れつつある点は見落とされやすいポイントです。

放置した場合に広がるリスク－新機能停止が意味すること

WSUSの非推奨化で最も直接的な影響は、新機能が追加されなくなる点です^*1。Azure Update ManagerやWindows Autopatchでは、再起動を必要としないホットパッチや、ドライバー配信の段階的ロールアウトといった機能強化が続けられています^*4。同様の強化がWSUS側に加わることは想定しにくく、クラウド型ツールとの機能差は時間の経過とともに広がっていくと考えられます。

もう一つの論点は、社内の更新管理体制がWSUS単独に依存し続けることの負担です。既存機能は維持されるとはいえ、新しい更新シナリオへの対応や運用の効率化はクラウド側の更新管理が担う領域になりつつあります^*1。判断を先送りにしたまま運用を続けると、後になって移行の検討期間を十分に確保できなくなる可能性があるでしょう。

後継となるクラウド更新管理の全体像

クライアント端末はWindows AutopatchとMicrosoft Intuneが担う

Windows Autopatch（Windows・Microsoft 365 Apps・Microsoft Edge・Microsoft Teamsの更新を自動化するMicrosoft製のクラウドサービス）は、対象デバイスへの更新配信内容を承認・管理する役割を担います^*4。Business Premium・A3以上・E3以上・F3のライセンスに含まれる権利が前提となり、更新リング・機能更新ポリシー・品質更新ポリシー・ドライバー更新ポリシーといった機能が利用できます^*4。

Microsoft Intune（クラウド上で端末の設定・更新を一元管理するMicrosoft製のサービス）は、更新リングやSettings Catalogを通じて更新ポリシーを構成します^*5。ポリシーを保存するとIntuneが設定内容をWindows Autopatchへ送り、Autopatchが配信を承認した更新だけが端末に届く仕組みです^*5。クライアント端末の更新管理は、この2つのサービスが連携して担う設計になっています。

サーバーはAzure Update Managerがオンプレミスも含めて担う

Azure Update Manager（Azure仮想マシンとオンプレミス・他クラウドのサーバーの更新状況を一元管理するMicrosoft製のサービス）は、Azure Arc（オンプレミスや他クラウドのサーバーをAzureの管理画面に登録し一元管理する仕組み）で接続したサーバーを含め、WindowsとLinuxの更新コンプライアンスを単一のダッシュボードで監視できます^*6。興味深いのは、WSUSに公開された更新プログラムを適用する機能も備えている点で、既存のWSUS運用資産を完全に切り離さずに移行を進められる余地があります^*6。

Azure Update Managerは、カスタマイズしたメンテナンス時間内での更新スケジュール設定や、再起動不要のホットパッチ適用にも対応します^*6。サーバー台数が多い企業ほど、単一のダッシュボードで更新状況を把握できる利点は大きくなるでしょう。

クラウド更新管理への移行手順

対象端末・サーバーの棚卸しと更新経路の整理

移行の第一歩は、クライアント端末とサーバーを分けて棚卸しすることです。クライアントはWindows AutopatchとIntune、サーバーはAzure Update Managerというように、管理対象と後継サービスの対応関係を整理する必要があります^*4*6。オンプレミスサーバーが多い場合は、Azure Arcへの登録作業が追加の工程になる点も踏まえておく必要があるでしょう。

ライセンス要件と対応エディションの確認

Windows Autopatchの各種ポリシーを利用するには、Business Premium・A3以上・E3以上・F3のいずれかのライセンスに含まれるAutopatchの権利が前提となります^*4。既存のライセンス体系がこの条件を満たしているかどうかを、移行計画の初期段階で確認しておくことが欠かせません。Azure Arc経由でサーバーを管理する場合も、対象OSやサブスクリプションの要件を事前に確認する必要があります^*6。

内製移行と外注委託のコスト構造比較

クラウド更新管理への移行は、内製で進める場合と外部パートナーへ委託する場合で、必要な知識と作業範囲が異なります。以下の表に主な違いを整理しました。

内製に必要なスキルと外注する場合の違い

内製で完結させる場合に求められる専門知識

WSUSからの移行を内製で完結させる場合、求められる知識は複数分野にまたがります。Windows Autopatchのライセンス要件確認とAutopatchグループ設計、Intuneでの更新リング・機能更新ポリシー・品質更新ポリシーの設定、Azure Arcを使ったオンプレミスサーバーの登録、Azure Update Managerでのメンテナンススケジュール設計がその内容です^*4*5*6。クライアントとサーバーの双方にまたがる知識を、限られた情報システム部門の人員でまかなえるかどうかが最初の関門になります。

判断を先送りにしたまま自己流で設定を進めると、更新リングの設計不備やAzure Arc登録の抜け漏れに後から気づくケースが生じかねません。特にライセンス要件を確認しないままAutopatch向けのポリシーを作成すると、対象デバイスに配信が反映されないといった手戻りにつながるおそれがあります^*4。

専門パートナーに委託した場合の違い

専門パートナーに依頼すると、対象端末・サーバーの棚卸しからポリシー設計、Azure Arcの登録作業、移行後の監視体制構築までを一貫して任せられます。自社では要件整理や動作検証だけで時間がかかる場面でも、複数の更新管理基盤を扱ってきた知見を活用すれば、移行までの期間を圧縮しやすくなるでしょう。内製と外注のどちらを選ぶ場合でも、まずは対象範囲とライセンス要件の整理が出発点になります。

まとめ：WSUS非推奨化後に検討すべき3つの判断軸

本稿では、Microsoftが2024年9月に発表したWSUSの非推奨化と、後継となるクラウド更新管理への移行について、公式情報に基づいて整理しました。要点は次の3つに集約されます。第一に、非推奨は新機能の追加停止を意味し、既存機能は当面継続しますが、放置すれば新しい更新シナリオへの対応で後れを取るリスクがあります^*1*3。第二に、クライアントはWindows AutopatchとIntune、サーバーはAzure Update Managerが後継の受け皿になります^*4*6。第三に、移行を内製で進めるか外部委託するかは、必要スキルと運用体制の両面から見極める必要があるでしょう。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Microsoft「Windows Server Update Services (WSUS) deprecation」Windows IT Pro Blog（https://techcommunity.microsoft.com/blog/windows-itpro-blog/windows-server-update-services-wsus-deprecation/4250436）（2024年9月）
2. *2　出典：Microsoft Learn「Windows Server Update Services (WSUS) Overview」（https://learn.microsoft.com/en-us/windows-server/administration/windows-server-update-services/get-started/windows-server-update-services-wsus）
3. *3　出典：Microsoft Learn「Features Removed or No Longer Developed in Windows Server」（https://learn.microsoft.com/en-us/windows-server/get-started/removed-deprecated-features-windows-server）
4. *4　出典：Microsoft Learn「What is Windows Autopatch?」（https://learn.microsoft.com/en-us/windows/deployment/windows-autopatch/overview/windows-autopatch-overview）
5. *5　出典：Microsoft Learn「Windows Update Management Overview – Microsoft Intune」（https://learn.microsoft.com/en-us/intune/device-updates/windows/）
6. *6　出典：Microsoft Learn「Azure Update Manager Overview」（https://learn.microsoft.com/en-us/azure/update-manager/overview）

Tweet