WSUSの代わりにAzure Update Managerを使うには?オンプレWindows ServerをAzure Arcで更新管理

Windows

WSUS(Windows Server Update Services)が非推奨となり、「今後Windows Serverの更新管理をどうすればよいのか」と考えている管理者も多いと思います。

その選択肢の一つが、Azure ArcとAzure Update Managerを組み合わせた更新管理です。

オンプレミスのWindows ServerをAzure Arcへ登録すると、Azure上に存在しないサーバーもAzureリソースとして管理できるようになります。

さらにAzure Update Managerを利用することで、更新プログラムの評価、適用、スケジュール管理などをAzure側から実行できます。

この記事では、WSUSとの違いも含めて、オンプレミスWindows ServerをAzure Update Managerで管理する流れを解説します。

WSUSからAzure ArcとAzure Update Managerへ段階移行する構成
オンプレミスWindows ServerをAzure Arcへ登録しAzure Update Managerで更新管理する構成

Azure Update ManagerはWSUSの代わりになる?

最初に理解しておきたいのは、Azure Update ManagerとWSUSは仕組みが同じではないという点です。

WSUSは、Microsoftから更新プログラムを同期し、管理者が承認した更新プログラムをクライアントやサーバーへ提供します。

一方、Azure Update Managerは更新ファイルそのものを配信するWSUSサーバーではありません。

WindowsではWindows Updateクライアントを利用して更新プログラムを取得・インストールし、Azure Update Managerはその評価や適用、スケジュールなどを管理します。

そのため、Azure Update Managerを導入したからといって、必ずWSUSを即座に撤去する必要はありません。

オンプレWindows Serverを管理するにはAzure Arcが必要

Azure VMであればAzure Update Managerから直接管理できます。

しかし、社内の物理サーバーやVMware、Hyper-Vなどで動作しているWindows ServerはAzure外のサーバーです。

これらをAzure Update Managerで管理するために利用するのがAzure Arc-enabled serversです。

Azure Arcを利用すると、Azure外に存在するWindows ServerやLinuxサーバーをAzureリソースとして登録できます。

例えば次のようなサーバーが対象になります。

  • 社内データセンターの物理Windows Server
  • Hyper-V上のWindows Server
  • VMware上のWindows Server
  • 他社クラウド上のWindows Server
  • Linuxサーバー

構成イメージ

オンプレミスWindows ServerをAzure Update Managerで管理する基本構成は次のようになります。

オンプレミス Windows Server
        ↓
Azure Connected Machine Agent
        ↓
Azure Arc
        ↓
Azure Update Manager
        ↓
更新プログラムの評価・適用・スケジュール管理

ただし、実際の更新プログラムの取得元はWindows Updateクライアント側の設定に従います。

そのため、

Windows Server
    ↓
Microsoft Update

という構成だけでなく、

Windows Server
    ↓
既存WSUS

という構成も可能です。

Azure Update Manager導入前の前提条件

Azure Update Managerでオンプレミスサーバーを管理するには、まず対象サーバーをAzure Arcへ接続する必要があります。

主な確認項目は次のとおりです。

  • Azureサブスクリプションがあること
  • Azure ArcでサポートされているOSであること
  • Azure Arc登録に必要な権限があること
  • 対象Windows Serverで管理者権限を使用できること
  • Azure Arcに必要な通信が許可されていること
  • Windows UpdateまたはWSUSへ通信できること

プロキシやファイアウォールでインターネット接続を制限している環境では、Azure ArcとWindows Updateの通信要件も事前に確認しておきましょう。

手順1:Windows ServerをAzure Arcへ登録する

Azure Arcへの登録方法はいくつか用意されています。

少数のサーバーを登録するのであれば、Azure Portalからインストールスクリプトを生成して実行する方法が分かりやすいでしょう。

大規模環境では、PowerShell、サービスプリンシパル、グループポリシー、Configuration Managerなどを利用した展開方法も用意されています。

Windows Serverのバージョンによっては、Windows Serverに用意されたAzure Arc Setupから登録することもできます。

Azure Portalから登録スクリプトを作成する

基本的な流れは次のとおりです。

  1. Azure Portalへサインインする
  2. Azure Arcを開く
  3. 「Servers」を選択する
  4. サーバー追加を開始する
  5. サブスクリプションを選択する
  6. リソースグループを選択する
  7. Azureリージョンを選択する
  8. 必要な設定を入力する
  9. インストールスクリプトを生成する

生成されたスクリプトを対象Windows Server上で管理者権限を使用して実行します。

Connected Machine Agentとは?

Azure Arcへの登録時には、対象サーバーへAzure Connected Machine Agentがインストールされます。

このエージェントによって、Azure外に存在するサーバーとAzure Arcを接続します。

接続が完了すると、オンプレミスWindows ServerがAzure Portal上のAzure Arc対応サーバーとして表示されます。

Azure Arcへの接続を確認する

登録後はAzure Portalから対象サーバーを確認します。

サーバーがAzure Arc対応サーバーとして正常に表示されていれば、Azure側から管理できる状態になっています。

いきなり本番サーバーを大量に登録するのではなく、最初は検証用Windows Serverを1台登録して動作を確認するのがおすすめです。

手順2:Azure Update Managerを開く

Azure Arcへの登録が完了したらAzure Update Managerを利用します。

Azure Update Managerでは、Azure VMだけでなくAzure Arc対応サーバーについても更新状況を確認できます。

主に次のような操作ができます。

  • 更新プログラムの評価
  • 適用可能な更新の確認
  • 更新プログラムのインストール
  • 更新結果の確認
  • 定期的な評価
  • スケジュールした更新

Update Manager用の拡張機能は自動的に導入される

Azure Update Managerを利用するためには、Azure Arc対応サーバー側にもUpdate Manager用の拡張機能が必要です。

ただし、通常は管理者が事前に手動インストールする必要はありません。

Microsoftによると、Azure Update Managerで最初に操作を実行すると、必要な拡張機能が自動的に展開されます。

手順3:更新プログラムを評価する

まずは対象サーバーにどの更新プログラムが必要なのか確認します。

Azure Update Managerから更新評価を実行すると、対象サーバーで不足している更新プログラムを確認できます。

いきなり更新を適用するのではなく、まず評価結果を見るところから始めると安全です。

手順4:テストサーバーへ更新を適用する

更新内容を確認したら、まずテスト用サーバーへ適用します。

本番環境では、WSUSと同様に段階的な更新を考えた方が安全です。

例えば、

  1. 検証サーバー
  2. 影響の少ないサーバー
  3. 一部の本番サーバー
  4. 残りの本番サーバー

という順番で適用します。

更新後には、OSだけでなく業務アプリケーションやサービスが正常に動作していることも確認しましょう。

手順5:スケジュール更新を設定する

検証ができたら、メンテナンス時間に合わせて定期的な更新を設定できます。

例えば、

  • 毎月第3土曜日
  • 深夜2時から
  • 検証グループを先に更新
  • 数日後に本番グループを更新

といった運用を検討できます。

既存のWSUS運用で「検証 → 承認 → 本番」という流れを作っている場合も、クラウド型更新管理へ移行する際には同じように段階展開を設計することが重要です。

既存WSUSを残したままAzure Update Managerを使える

WSUSを運用している環境では、ここが非常に重要です。

Azure Update ManagerはWSUSを更新元として利用できます。

Windows Updateクライアントが既存WSUSを参照するようグループポリシーで設定されている場合、Update Managerはその設定を利用できます。

つまり、

Azure Update Manager
        ↓
Azure Arc
        ↓
Windows Server
        ↓
既存WSUS

という構成が可能です。

最初からWSUSを撤去するのではなく、Azure ArcとAzure Update Managerを追加して管理方法を検証し、その後に更新元をどうするか検討できます。

WSUSからMicrosoft Updateへ変更するときの注意

Azure Update Managerには、WSUSからMicrosoft Updateへ更新元を変更する機能があるわけではありません。

更新元はWindows Updateクライアントの設定で決まります。

Microsoftも、WSUSからMicrosoft Updateなどへパッチソースを変更する場合は、Windowsの設定やグループポリシーを使用するよう案内しています。

そのためWSUS移行時には、既存GPOを必ず確認しましょう。

WSUS設定が残っていないか確認する

WSUS環境では、次のレジストリ付近にWindows Update関連ポリシーが設定されていることがあります。

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate

WSUSサーバーを指定するGPOなどが残っている状態でWSUSだけ撤去すると、Windows Serverが更新プログラムを取得できなくなる可能性があります。

「WSUSサーバーを止めれば自動的にMicrosoft Updateへ切り替わる」と考えず、既存ポリシーを確認してから移行しましょう。

Azure Update ManagerとGPOの競合にも注意

Windows Updateの動作はグループポリシーによって細かく制御できます。

既存環境で自動更新、再起動、WSUSサーバーなどをGPOで設定している場合は、新しい更新管理方式と意図しない競合が起きないか確認する必要があります。

特に長期間WSUSを利用しているActive Directory環境では、過去に作成されたWindows Update関連GPOが残っていないか確認しておきましょう。

Azure Update Managerでは更新プログラムを事前ダウンロードできない

WSUSとの違いとして注意したい点があります。

Microsoftの公式ドキュメントでは、Azure Update Managerは更新プログラムの事前ダウンロードをサポートしていません。

WSUSでは更新ファイルを社内側へ保持して配信する構成ができますが、Azure Update Managerは同じ仕組みではありません。

多数のサーバーを管理する場合は、インターネット回線や既存WSUSの利用を含め、更新ファイルをどこから取得するかも設計する必要があります。

おすすめは段階移行

既にWSUSが安定して動いているのであれば、いきなり撤去する必要はありません。

例えば次のように段階的に移行できます。

  1. 既存WSUSはそのまま運用する
  2. 検証用Windows ServerをAzure Arcへ登録する
  3. Azure Update Managerから更新状態を確認する
  4. WSUSを更新元としたまま更新適用を試す
  5. 運用方法や費用、通信要件を確認する
  6. 一部サーバーから新しい更新方式へ移行する
  7. 問題がなければ対象を拡大する

この方法なら、既存WSUS環境を壊さずにAzure Update Managerを検証できます。

まとめ

WSUSが非推奨となったことで、今後のWindows Server更新管理を考える必要があります。

その有力な選択肢の一つが、Azure ArcとAzure Update Managerです。

ポイントをまとめると、

  • オンプレWindows ServerはAzure Arcへ登録する
  • Connected Machine AgentでAzureと接続する
  • Azure Update Managerから更新を評価・適用できる
  • スケジュールした更新も可能
  • 既存WSUSを更新元として残すこともできる
  • 更新元の変更はUpdate ManagerではなくGPOなどで行う
  • 既存のWindows Update関連GPOに注意する
  • まずテストサーバーから段階的に導入する

WSUSが非推奨になったからといって、すぐにWSUSを撤去する必要はありません。

「WSUSを残したままAzure ArcとAzure Update Managerを試し、少しずつ新しい更新管理へ移行する」という方法も現実的です。

次回のWindows Server更改を予定している場合は、WSUSをそのまま新規構築するだけでなく、Azure Update Managerも比較対象にしてみるとよいでしょう。

参考情報

コメント

タイトルとURLをコピーしました