※本記事は2026年3月時点の情報です。実際の移行作業は貴社環境で検証を行い、Microsoft公式ドキュメントを確認の上、自己責任で実施してください。
WSUSからIntune移行を考え始めたあなたへ
2023年、MicrosoftはWSUSを非推奨と発表した。
「えっ、じゃあもう使えないの?」と焦った人も多いだろう。安心してほしい。すぐに使えなくなるわけではない。製品ライフサイクルに従ってセキュリティ更新は提供され続ける。
それでも、多くの企業がIntuneへの移行を検討し始めている。理由は単純で、WSUSの運用工数を削減でき、リモートワーク時代に適したクラウド管理が実現できるからだ。
私は10年以上WSUSを運用してきた。サーバーの容量不足に悩み、月次の更新承認作業に追われ、クリーンアップに時間を取られてきた。正直、面倒だった。
Intune移行は簡単ではない。でも、計画的に進めれば確実に運用負荷は下がる。この記事では、WSUS管理者の視点から実務的な手順と現場で直面する課題への対処法を解説する。
Intuneに移行すると何が変わるのか
まず、Intuneに移行すると何が変わるのか。大きく3つのメリットがある。
サーバー運用から解放される
WSUSはWindows Server上で動作する。サーバーを維持管理する必要があった。
ディスク容量の監視、定期的なクリーンアップ、データベースのメンテナンス。毎月のように「また容量不足か」と頭を抱えた経験はないだろうか。
Intuneは完全なクラウドサービスなので、これらの作業がすべて不要になる。サーバーを意識する必要がない。
リモートワークに対応できる
WSUSは社内ネットワークを前提とした設計だった。リモートワーク中の社員がWindows Updateを受け取るには、VPN接続が必要だった。
「VPNつながらないんですけど」という問い合わせに対応した経験、誰にでもあるはずだ。
Intuneならインターネット接続さえあれば、どこからでも更新を受け取れる。営業で外回りの多い社員や在宅勤務の社員にとって、これは大きなメリットだ。
Windows以外のデバイスも管理できる
WSUSはWindowsのみの管理だった。IntuneならmacOS、iOS、Androidデバイスも一元管理できる。
今後、社用スマホやタブレットを導入する予定があるなら、Intuneへの移行は先行投資になる。
移行前に知っておくべき3つの課題
メリットばかりではない。移行にはいくつか課題もある。
ライセンスコストがかかる
Intuneを利用するには、Microsoft 365 E3/E5、Business Premium、またはEnterprise Mobility + Securityのいずれかのライセンスが必要だ。
ただし、既にMicrosoft 365を契約している企業なら、追加コストなしで使える可能性が高い。まずは現在のライセンスを確認しよう。
ネットワーク帯域が圧迫される可能性
WSUSはサーバー経由で更新を配信するため、社内LANの帯域で完結できた。
Intuneでは、各端末がMicrosoft Updateから直接ダウンロードする。そのため、インターネット回線の帯域が圧迫される可能性がある。
対策として、配信の最適化機能を使えば、社内LAN上でピアツーピア共有ができる。これで帯域の問題はある程度緩和される。
細かい制御がしにくくなる
WSUSでは、個別の更新プログラムを承認・拒否できた。問題のある更新だけを除外し、他は承認する運用が可能だった。
Intuneでは、更新プログラムを個別に承認する機能はない。代わりに「リリースから7日後に配信」といった延期期間を設定する形になる。
この点は、WSUS管理者にとって最も戸惑うポイントかもしれない。慣れるまで時間がかかる。
Intuneを使うために必要なもの
ライセンスの確認
Intuneを利用できるライセンスは以下の通り。
- Microsoft 365 E3/E5
- Microsoft 365 Business Premium
- Enterprise Mobility + Security E3/E5
- Intune単体ライセンス
注意点として、Microsoft 365 Business Standardには含まれない。
Azure ADへのデバイス登録
IntuneはAzure AD(最近はMicrosoft Entra IDと呼ばれる)と連携して動作する。端末がAzure ADに登録されていないと、Intuneで管理できない。
既存のオンプレミスActive Directoryを使っている企業なら、ハイブリッドAzure AD参加を設定すれば、既存のADをそのまま使いながらIntuneを導入できる。完全にクラウド移行する必要はない。
段階的移行を強く推奨する理由
いきなり全端末をIntuneに移行するのは危険だ。トラブルが発生したとき、影響範囲が大きすぎる。
段階的に進めるメリットは3つある。
- トラブルが発生しても影響を最小限に抑えられる
- 各フェーズで検証しながら進められる
- 問題があればロールバックできる
推奨する移行スケジュールを紹介する。
フェーズ1: テストグループで試してみる(1〜2ヶ月)
まず5〜10台のテスト端末でIntuneを試す。IT部門の端末や、トラブルが起きても業務に影響の少ない端末を選ぶのがコツだ。
この段階で以下を確認する。
- Azure ADへのデバイス登録が正常に動作するか
- Intuneポリシーが正しく適用されるか
- Windows Updateが配信されるか
- 既存の業務アプリが問題なく動作するか
ここで問題が出たら、本番展開前に対処法を確立できる。
フェーズ2: 部門ごとに段階的に展開(2〜4ヶ月)
テストが成功したら、部門ごとに段階的に展開する。
推奨する順序は以下の通り。
- IT部門(トラブル対応がしやすい)
- 営業部門(外出が多く、クラウド管理のメリットが大きい)
- 管理部門(業務が安定している)
- 開発部門(特殊な環境が多いため最後)
各部門の移行後、1〜2週間の安定稼働を確認してから次に進む。焦らないことが重要だ。
フェーズ3: 全社展開とWSUS廃止(1〜2ヶ月)
全端末がIntuneに移行したら、WSUS+Intuneの並行運用期間を設ける。最低でも1ヶ月、できれば2ヶ月は並行運用したい。
この期間に、月次のパッチチューズデーを2回経験し、問題がないことを確認する。
問題なければ、WSUSサーバーを停止する。ただし、すぐに削除はしない方がいい。1〜2ヶ月はバックアップとして残しておくことを推奨する。
具体的な移行手順
ステップ1: 現在のWSUS環境を棚卸しする
まず、現在のWSUS環境を正確に把握する。
- 管理対象の端末数
- OSバージョンの分布
- 現在の更新承認ポリシー
- コンピューターグループの構成
WSUSサーバーで以下のPowerShellコマンドを実行すると、管理対象端末の情報を取得できる。
$wsus = Get-WsusServer $wsus.GetComputerTargets().Count $wsus.GetComputerTargets() | Group-Object -Property OSDescription | Select-Object Name, Count
※上記コマンドは環境によって動作が異なる場合があります。実行前に検証環境でテストしてください。
ステップ2: デバイスをAzure ADに参加させる
既存のドメイン参加端末を、ハイブリッドAzure AD参加に変更する。
グループポリシーで以下を設定する。
Computer Configuration > Policies > Administrative Templates > Windows Components > Device Registration "Register domain-joined computers as devices" を有効化
または、Azure AD Connectで自動登録を設定することもできる。Azure AD Connectの方が設定は簡単だ。
ステップ3: Intuneへの自動登録を設定する
Azure AD管理センターで、Windowsデバイスの自動登録を有効化する。
デバイス→登録→Windowsの自動登録から、MDMユーザースコープを「すべて」または「一部」に設定する。
最初は「一部」に設定して、テストグループのみを対象にするのが安全だ。
ステップ4: Windows Updateポリシーを作成する
Intune管理センターで、Windows Updateの配信ポリシーを作成する。
デバイス→Windows→Windows 10以降の更新リングから、新しいポリシーを作成する。
設定例は以下の通り。
- 品質更新プログラムの延期期間: 7日
- 機能更新プログラムの延期期間: 30日
- 自動更新の動作: 自動的にインストールしてメンテナンス時刻に再起動
- アクティブ時間: 8時〜18時
WSUSと同じ運用にしたいなら、延期期間をWSUSでの承認タイミングに合わせればいい。
ステップ5: WSUSからIntuneに切り替える
クライアント側のWSUS設定を削除し、Intuneからの更新配信に切り替える。
以下のPowerShellコマンドで、WSUS設定を削除できる。
Remove-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" -Name "WUServer" -ErrorAction SilentlyContinue Remove-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" -Name "WUStatusServer" -ErrorAction SilentlyContinue Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" -Name "UseWUServer" -Value 0 Restart-Service wuauserv
または、グループポリシーでWSUS設定を削除し、gpupdate /forceを実行する方法もある。グループポリシーの方が一括管理しやすい。
※上記の操作は環境によって影響が異なります。必ずテスト環境で検証してから実施してください。
よくあるトラブルと対処法
デバイスがIntuneに登録されない
原因として考えられるのは、Azure ADへの参加が完了していないか、自動登録が有効になっていないケース。
dsregcmd /statusコマンドで、Azure AD参加状態を確認できる。AzureAdJoinedがYESになっていれば正常に参加している。
また、Azure AD管理センターで自動登録設定を再確認し、端末を再起動してから再度確認する。再起動で解決することも多い。
更新プログラムが配信されない
原因として、ポリシーが正しく適用されていないか、延期期間の設定ミスが考えられる。
Intune管理センターでデバイスの状態を確認し、クライアント側でgpresult /h report.htmlを実行してポリシー適用状況を確認する。
また、Windows Updateのトラブルシューティングツールを実行すると、問題を自動検出できる場合がある。設定→更新とセキュリティ→トラブルシューティングから実行できる。
ネットワーク帯域が圧迫される
全端末が一斉にMicrosoft Updateからダウンロードすると、インターネット回線が圧迫される。
対策として、配信の最適化を有効化する。これで、社内LAN上でピアツーピア共有ができ、インターネット帯域の消費を抑えられる。
Intune管理センター→デバイス→構成プロファイル→配信の最適化から設定できる。
また、更新リングを複数作成して段階的に配信する方法も有効だ。グループAは7日延期、グループBは14日延期といった設定にすれば、一斉ダウンロードを避けられる。
WSUS+Intune並行運用期間の過ごし方
移行直後は、WSUSとIntuneを並行運用することを強く推奨する。
並行運用が必要な理由
- トラブル発生時にロールバックできる
- 段階的な移行が可能
- 影響を最小化できる
並行運用の注意点
端末ごとに、WSUSまたはIntuneのいずれか一方のみを有効にする。両方が有効だと、更新プログラムの配信が競合してしまう。
グループAはWSUS、グループBはIntuneという形で明確に分ける。
並行運用を終了するタイミング
以下の条件をすべて満たしたら、WSUSを停止してよい。
- 全端末がIntuneに移行完了
- パッチチューズデーを2回以上経験
- 重大なトラブルが発生していない
- ユーザーからの問い合わせが落ち着いた
- Intune管理センターで全端末の状態を確認済み
焦らず、確実に移行できたことを確認してから廃止しよう。
移行後の運用で気をつけること
定期的な確認作業
- 月1回: Intune管理センターで更新状況を確認
- 四半期ごと: 更新ポリシーの見直し
- 年1回: ライセンス利用状況の確認
WSUS時代と同じように、定期的な確認作業は必要だ。
配信の最適化を活用する
Delivery Optimizationを有効にすれば、インターネット帯域を大幅に削減できる。
Intune管理センター→デバイス→構成プロファイル→配信の最適化から設定する。
おすすめの設定は以下の通り。
- ダウンロード モード: HTTPとLAN上のピアリング
- 最小RAMサイズ: 4GB
- 最小ディスク容量: 32GB
焦らず計画的に進めることが成功のカギ
WSUS→Intune移行は、一朝一夕には完了しない。焦らず、段階的に、確実に進めることが重要だ。
全体のスケジュールとしては、5〜7ヶ月を見込んでおくのが現実的だろう。
- 現状把握: 1週間
- 前提条件確認: 2〜3日
- テスト環境構築: 1〜2週間
- 移行計画策定: 1週間
- 段階的移行: 2〜3ヶ月
- 並行運用・WSUS廃止: 1〜2ヶ月
このロードマップを参考に、自社の環境に合わせた移行計画を立ててみてほしい。
※免責事項: 本記事の内容は一般的な情報提供を目的としており、特定の環境における動作を保証するものではありません。実際の移行作業は、必ず貴社環境で検証を行い、Microsoft公式ドキュメントを確認の上、自己責任で実施してください。
関連記事
WSUS→Intune移行について、さらに詳しく知りたい方は以下の記事も参照してください。
- WSUSからIntuneへの移行ロードマップ – 何から始めればいいかわからない方向け
- WSUS担当者がIntuneを触る前に知っておくべき概念の違い5つ – 設計思想の違いを理解する
- WSUSとIntuneの併用期間はどのくらい必要か – 並行運用のベストプラクティス
- Intune移行にかかる費用と工数の現実 – 予算計画に必須
- WSUSで管理していたWindows Updateポリシー、Intuneではどこで設定するのか – 具体的な設定場所
