WSUSが非推奨となるアナウンス出たことを書いたら結構読まれてびっくりです。ありがとうございます。今後のパッチ管理はこんな感じにしたいんでしょうかね 。
- 10台くらいまでのSMB：ADのドメインコントローラーのような例外を除いてWindows Updateに任せる
- 100台くらいまで：Azure Update Managerにつないで管理
- それ以上System Center使うよね？
いつもは「クラウドに移行しましょう」みたいなことを言いますが、今回に限っては「あと5年くらいはWSUSつかいつづけてもいいんじゃね？」というのが個人的なスタンスです。
というかですね。Azureのこの手のサービスで5年続いたものって多くない。 Azure Update Managerも前身のAzure Automation Update ManagementのGAが2018年で、6年ほどです。移行期間を入れると5年かどうかというところでしょう。なので、今のところはWindows Server 2025のWSUSに移行して、標準サポート終わるくらいまでの間状況をウォッチしておけばいいんじゃないかなと思います。Windows Server 2025はArcにつなぐとHotpatchが使えるので年4回の再起動でよくなるみたいですしね（もちろんWSUSが使うSQL Serverなどのパッチインストール後再起動を要求すると別です）。
今は移行ではなく、評価としてAzure Update Managerを試しておくのは悪くないと思います。ESUの運用やWindows Server 2025のHotpatchで必要になるからついでにという人もいるでしょう。
普通に使う方法はいくらでも載っているので、実際の運用でAzureポータルへのアクセス権を渡したくない、という場合を考えてみます。ぱっと思いつくのがPower BIです。
Azure Resource QueryをPower BIから発行してビジュアライズします。
patchinstallationresources | where type has 'softwarepatches' and properties !has 'version' | extend machineName = tostring(split(id, '/', 8)), resourceType = tostring(split(type, '/', 0)), tostring(rgName = split(id, '/', 4)), tostring(RunID = split(id, '/', 10)) | extend prop = parse_json(properties) | extend lTime = todatetime(prop.lastModifiedDateTime), patchName = tostring(prop.patchName), kbId = tostring(prop.kbId), installationState = tostring(prop.installationState), classifications = tostring(prop.classifications) | where lTime > ago(7d) | project lTime, RunID, machineName, rgName, resourceType, patchName, kbId, classifications, installationState | sort by lTime desc
KQL力がないのでサンプルそのまま。Projectの部分はもうちょっといじれると思います。
で、これをPower BIに発行するとこんな感じ。
毎日更新したいのでセマンティックモデルを定期更新します。とりあえず毎日一度にしています。
Power BIのライセンスは必要ですが、Azureポータルにアクセスしなくても見えるので便利かなと思います。もしくはSharePointに貼り付けでもいいでしょう。
Update Managerは現状の適用状態を取得するしかなく、どんなパッチがリリースされているかはまったくわかりません。 データ抜くところは全然足りないので、この辺がResource Graphで取得できたらいいなぁとか、反映がかなり遅いので（Windowsでは適用済みでもAzureポータルでは未適用とか出る）、ここ何とかしてほしいとは思っています。
