Microsoft AzureのAz.DesktopVirtualizationを使ってAzure Virtual Desktopを自動化している場合、2026年5月20日にマージされた「New package for Az.DesktopVirtualization based on 2025-10-10」は確認しておきたい更新です。結論から言うと、主なポイントは DesktopVirtualization APIの2025-10-10対応、HostPoolのMultiplePersistent対応、登録トークン操作の修正、そしてUpdate-AzWvdApplication／Update-AzWvdDesktopの-Tag削除予定 です。特にPowerShellスクリプトやCI/CDでAVD環境を作成・更新している管理者は、リリース適用前にコマンドレットのパラメーター差分を確認しておくべきです。該当PRはAzure PowerShellのmainブランチへ2026年5月20日にマージされており、157ファイル規模の変更として、APIバージョン更新、ヘルプ更新、テスト更新、登録トークン処理の調整が含まれています。(GitHub)
今回のMicrosoft Azure更新で何が変わるのか
今回の更新は、Azure PowerShellのAz.DesktopVirtualizationモジュールを、DesktopVirtualizationの2025-10-10 APIに合わせるためのパッケージ更新です。Azure Virtual Desktopそのものの管理画面が大きく変わるというより、PowerShellからホストプール、ワークスペース、アプリケーショングループ、アプリ、デスクトップ、スケーリングプランなどを操作する際のAPI面・パラメーター面が更新されると捉えると分かりやすいです。
公式のChangeLogでは、Upcoming Releaseとして次の3点が示されています。APIバージョンの2025-10-10への更新、HostPoolのloadBalancerTypeにMultiplePersistent列挙値が追加されたこと、そしてパブリックネットワークアクセスを無効化したホストプールでNew-AzWvdRegistrationInfoとRemove-AzWvdRegistrationInfoが失敗する問題の修正です。(GitHub)
| 変更点 | 実務上の意味 | 優先度 |
|---|---|---|
APIバージョンが2025-10-10ベースに更新 | 新しいDesktopVirtualization API仕様に合わせてPowerShellモジュールが再生成される | 高 |
loadBalancerTypeにMultiplePersistent追加 | 個人用ホストプールで複数の永続デスクトップ割り当てを扱う構成に関係する | 高 |
| 登録トークン操作の修正 | PublicNetworkAccessを無効化したホストプールでトークン作成・削除の自動化が改善される | 高 |
| ヘルプ・参照ドキュメント更新 | IdentityTypeなどの説明やパラメーター表示が整理される | 中 |
-Tag削除予定の事前告知 | Update-AzWvdApplication、Update-AzWvdDesktopを使うスクリプトの修正が必要になる可能性 | 高 |
注意したいのは、PRがマージされたことと、自分の環境でそのモジュールがすでに利用可能であることは同じではない点です。運用環境では、PowerShell Gallery、Azure PowerShellのリリースノート、Azure AutomationやDevOpsエージェントに導入されている実際のモジュールバージョンを必ず確認してください。
影響を受けやすい利用者
今回のMicrosoft Azure更新で特に影響を受けやすいのは、Azure Virtual DesktopをPowerShellで管理している管理者と、デプロイ処理を自動化している開発者です。Azure Portalだけで手動管理している場合、影響は限定的です。ただし、将来的に自動化へ移行する予定があるなら、今のうちにコマンドレットの変更点を把握しておく価値があります。
| 対象者 | 確認すべき内容 |
|---|---|
| AVD管理者 | ホストプールのLoadBalancerType、PublicNetworkAccess、登録トークン運用 |
| PowerShell運用担当 | Az.DesktopVirtualizationのバージョン、利用中コマンドレットのパラメーター |
| CI/CD担当 | Azure DevOps、GitHub Actions、Azure Automationで固定しているモジュールバージョン |
| セキュリティ担当 | パブリックネットワークアクセス無効化環境での登録トークン操作、トークンのログ出力有無 |
| 開発者 | Update-AzWvdApplication、Update-AzWvdDesktopの-Tag依存コード |
特に見落としやすいのは、ローカルPCでは新しいモジュールを検証しているのに、Azure Automationアカウントやビルドエージェントでは古いAz.DesktopVirtualizationが使われ続けるケースです。AVDの作成・更新スクリプトは一度動くと長期間見直されないことが多いため、リリース前後でパラメーター差分を確認する運用を入れておくと障害を避けやすくなります。
HostPoolのMultiplePersistent追加で確認すべきこと
今回の更新で分かりやすい機能面の変更は、HostPoolのloadBalancerTypeにMultiplePersistentが追加されたことです。2025-10-10 API仕様では、loadBalancerTypeの値としてBreadthFirst、DepthFirst、Persistent、MultiplePersistentが定義されています。(GitHub)
ここで混同しやすいのが、プール型ホストプールの負荷分散と、個人用ホストプールの永続割り当てです。Microsoft Learnでは、プール型ホストプールの負荷分散アルゴリズムとしてBreadth-firstとDepth-firstが説明されています。一方、複数の個人用デスクトップ割り当てを有効化する手順では、個人用ホストプールに対してPersonalDesktopAssignmentTypeをDirectにしたうえで、LoadBalancerTypeをMultiplePersistentに更新する例が示されています。(Microsoft Learn)
実務では、次のように判断すると安全です。
| 状況 | 推奨される確認 |
|---|---|
| プール型ホストプールを運用している | BreadthFirstまたはDepthFirstの設計意図を再確認する |
| 個人用ホストプールを運用している | PersistentとMultiplePersistentのどちらが要件に合うか確認する |
| 複数の個人用デスクトップ割り当てを検討している | PersonalDesktopAssignmentTypeがDirectであることを確認する |
既存スクリプトでLoadBalancerTypeを固定している | 新しい値に未対応のバリデーションや独自チェックがないか確認する |
検証時は、いきなり本番ホストプールへ適用しないでください。特にユーザー割り当て、既存セッション、運用中のセッションホスト数に影響するため、検証用ホストプールで挙動を確認してから展開するのが現実的です。
$rg = "rg-avd-prod"
$hostPool = "hp-avd-personal"
Update-AzWvdHostPool `
-ResourceGroupName $rg `
-Name $hostPool `
-PersonalDesktopAssignmentType "Direct"
Update-AzWvdHostPool `
-ResourceGroupName $rg `
-Name $hostPool `
-LoadBalancerType "MultiplePersistent"独自の入力チェックを入れているスクリプトでは、LoadBalancerTypeの許可値がBreadthFirst、DepthFirst、Persistentだけになっていないか確認してください。ここを見落とすと、Azure側では対応済みでも社内スクリプト側でエラーになります。
登録トークン操作の修正はPrivate Link運用で重要
今回のChangeLogで重要なのが、New-AzWvdRegistrationInfoとRemove-AzWvdRegistrationInfoに関する修正です。公式ChangeLogでは、ホストプールのパブリックネットワークアクセスが無効な場合にこれらのコマンドレットが失敗する問題が修正されたと記載されています。(GitHub)
これは、Azure Virtual Desktopのホストプールをより閉域寄りに運用している組織にとって重要です。PublicNetworkAccessを無効化し、Private Endpointやネットワーク制御を組み合わせている環境では、登録トークンの作成・削除が自動化のボトルネックになりやすいためです。
更新後の実装では、New-AzWvdRegistrationInfoは内部的にUpdate-AzWvdHostPoolを呼び出し、RegistrationInfoRegistrationTokenOperationにUpdateを指定して登録情報を作成する形になっています。Remove-AzWvdRegistrationInfoも同様に、Update-AzWvdHostPoolへDelete操作を渡す実装です。(GitHub)
検証する場合は、次のような観点で確認します。
| 確認項目 | 理由 |
|---|---|
| 登録トークンを作成できるか | セッションホスト追加や再登録の自動化に影響する |
| 登録トークンを削除できるか | 不要なトークンを残さないため |
| トークンがログに出力されていないか | 登録トークンは機密情報として扱う必要がある |
| 有効期限が長すぎないか | 漏えい時のリスクを下げるため |
| Azure AutomationやCI/CDでも同じ挙動になるか | 実行環境によってモジュールバージョンが異なることがあるため |
$rg = "rg-avd-prod"
$hostPool = "hp-avd-prod"
$expires = (Get-Date).ToUniversalTime().AddHours(4).ToString("yyyy-MM-ddTHH:mm:ss.fffffffZ")
$registrationInfo = New-AzWvdRegistrationInfo `
-ResourceGroupName $rg `
-HostPoolName $hostPool `
-ExpirationTime $expires
# トークンはログや画面共有に残さない
$registrationInfo.Token
Remove-AzWvdRegistrationInfo `
-ResourceGroupName $rg `
-HostPoolName $hostPool失敗しやすいポイントは、修正内容を「ネットワーク制限を気にしなくてよくなった」と解釈してしまうことです。今回の修正はコマンドレット動作の改善であり、RBAC、Private Endpoint、実行元ネットワーク、Azure AutomationのマネージドID権限などが不要になるわけではありません。
-Tag削除予定はスクリプト修正が必要になる可能性がある
今回の更新とあわせて、Az.DesktopVirtualization 6.0.0に向けた破壊的変更の事前告知も重要です。Microsoft LearnのAzure PowerShellリリースノートでは、Az.DesktopVirtualization 5.4.7において、Update-AzWvdApplicationとUpdate-AzWvdDesktopの-Tagパラメーター削除予定が事前告知されています。(Microsoft Learn)
さらに、今後の破壊的変更ページでは、Update-AzWvdApplicationとUpdate-AzWvdDesktopの-Tagが削除される変更は2026年6月2日に有効となり、Azバージョン16.0.0、Az.DesktopVirtualizationバージョン6.0.0から有効になる見込みとされています。(Microsoft Learn)
現在の参照ドキュメント上ではUpdate-AzWvdApplicationの構文に-Tag <Hashtable>が表示されていますが、これは将来の削除予定と矛盾するものではありません。つまり、「今は使える環境があるが、次のメジャー更新で使えなくなる可能性が高い」と考えて準備するのが安全です。(Microsoft Learn)
まず、既存スクリプトに-Tag依存がないか確認します。
Get-ChildItem -Path . -Recurse -Filter *.ps1 |
Select-String -Pattern "Update-AzWvd(Application|Desktop).*?-Tag", "\.Tag\s*="該当するコードが見つかった場合は、次の方針で見直します。
| 現在の実装 | 見直し方針 |
|---|---|
Update-AzWvdApplication -Tag @{...}を使っている | アプリ更新処理からタグ更新を分離する |
Update-AzWvdDesktop -Tag @{...}を使っている | デスクトップ更新処理からタグ更新を分離する |
| タグを運用分類に使っている | ホストプール、アプリケーショングループ、ワークスペースなど、タグ管理に適した上位リソースへ寄せる |
| タグを課金・棚卸しに使っている | 削除対象コマンドレットに依存しない棚卸し設計へ変更する |
修正時にやってはいけないのは、エラーを避けるために単に-Tagだけ削除し、分類情報の管理方法を決めないまま本番反映することです。タグを棚卸し、責任部署、環境区分、コスト配賦に使っている場合、タグ更新処理を削除すると運用レポート側に影響が出る可能性があります。
管理者が最初に実行すべき確認コマンド
更新の影響を把握するには、まず自分の実行環境でどのバージョンのAz.DesktopVirtualizationを使っているか確認します。
Get-Module Az.DesktopVirtualization -ListAvailable |
Sort-Object Version -Descending |
Select-Object Name, Version, Path次に、実際に読み込まれているコマンドレットのパラメーターを確認します。
Import-Module Az.DesktopVirtualization
(Get-Command Update-AzWvdApplication).Parameters.Keys -contains "Tag"
(Get-Command Update-AzWvdDesktop).Parameters.Keys -contains "Tag"
(Get-Command Update-AzWvdHostPool).Parameters.Keys -contains "LoadBalancerType"
(Get-Command Update-AzWvdHostPool).Parameters.Keys -contains "IdentityType"AVD環境側の状態も確認します。
$rg = "rg-avd-prod"
$hostPool = "hp-avd-prod"
Get-AzWvdHostPool `
-ResourceGroupName $rg `
-Name $hostPool |
Select-Object Name, HostPoolType, LoadBalancerType, PersonalDesktopAssignmentType, PublicNetworkAccessここで確認すべきポイントは、コマンドが成功するかどうかだけではありません。運用で使っているスクリプトの前提と、実際のホストプール設定が一致しているかを見ることが重要です。例えば、個人用ホストプールなのにプール型前提の負荷分散チェックをしている、PublicNetworkAccessを無効化しているのに登録トークン作成を古いモジュールで実行している、といったズレが障害につながります。
展開時の注意点
Az.DesktopVirtualizationの更新は、単にUpdate-Moduleを実行すれば終わりではありません。PowerShellモジュールは、ローカル端末、管理サーバー、Azure Automation、Functions、DevOpsエージェントなど、複数の実行場所に分散していることが多いためです。
安全に展開するには、次の順番で進めます。
| 手順 | 作業内容 | 失敗しやすいポイント |
| -: | —————————– | ——————————— |
| 1 | 現在のモジュールバージョンを棚卸しする | 管理者端末だけ確認して、Automation環境を見落とす |
| 2 | -Tag利用箇所を検索する | JsonStringや独自オブジェクト経由のタグ指定を見落とす |
| 3 | 検証環境で新バージョンを適用する | 本番ホストプールで直接試す |
| 4 | 登録トークン作成・削除を検証する | トークンをログに残す |
| 5 | MultiplePersistent利用有無を判断する | プール型ホストプールに誤って適用する |
| 6 | CI/CDのモジュール固定を見直す | エージェントごとに異なるバージョンで動く |
モジュール更新を行う場合は、本番環境で一括更新する前に、検証用のPowerShell環境で差分を確認してください。
# 例: インストール済みAz関連モジュールの確認
Get-InstalledModule Az* |
Sort-Object Name |
Select-Object Name, Version
# 例: Az.DesktopVirtualizationのみ更新する場合
Update-Module Az.DesktopVirtualization組織によっては、Az全体を更新するより、対象モジュールだけを段階的に更新した方が安全です。特にAzメジャーバージョン更新では他のAzureサービス用モジュールにも破壊的変更が含まれることがあるため、AVDだけの変更として扱わず、Azure PowerShell全体のリリース計画と合わせて判断してください。
開発者が見るべきコード上の変更
開発者や自動化担当者にとって重要なのは、今回の更新が生成コード・ヘルプ・テスト・UXメタデータを含む広い変更である点です。PRのレビュー概要では、DesktopVirtualization UX APIバージョンの2025-10-10への更新、ヘルプや参照ドキュメントの更新、New-AzWvdRegistrationInfo／Remove-AzWvdRegistrationInfoのカスタム実装調整が挙げられています。(GitHub)
また、生成設定では2025-10-10のREST API仕様ファイルが入力として指定されています。Update-AzWvdApplicationとUpdate-AzWvdDesktopのTagパラメーターについては、6.0.0およびAz16.0.0での破壊的変更として設定されています。(GitHub)
開発者が確認すべき代表的なポイントは次の通りです。
Update-AzWvdApplication、Update-AzWvdDesktopを直接呼ぶコードIApplicationPatchやIDesktopPatch相当のオブジェクトにTagを設定しているコードLoadBalancerTypeの値を独自にenum化しているコードNew-AzWvdRegistrationInfoの戻り値からトークンを取得している処理PublicNetworkAccessを無効化したホストプールを前提とするテスト- Azure Automationやパイプラインでモジュールバージョンを暗黙的に取得している処理
とくにCI/CDでは、Install-Module Az -Forceのように毎回最新を取得する構成は避けた方が安全です。リリースタイミングによって突然パラメーターが変わり、前日まで成功していたデプロイが失敗する可能性があります。少なくとも本番パイプラインでは、検証済みのバージョンを明示し、更新時にテストを通す運用にしてください。
すぐに取るべきアクション
今回のMicrosoft Azure更新に対して、管理者が最初にやるべきことは大きく3つです。
まず、利用中のAz.DesktopVirtualizationバージョンと実行場所を棚卸しします。次に、Update-AzWvdApplicationとUpdate-AzWvdDesktopで-Tagを使っているスクリプトを洗い出します。最後に、ホストプールのLoadBalancerType、PublicNetworkAccess、登録トークン作成・削除処理を検証環境で確認します。
特に、次の条件に当てはまる環境では優先度を上げてください。
| 条件 | 優先度を上げる理由 |
|---|---|
| AVDホストプールをPowerShellで作成・更新している | パラメーター変更の影響を受けやすい |
| Azure Automationでセッションホスト登録を自動化している | 登録トークン処理が運用に直結する |
Private EndpointやPublicNetworkAccess無効化を使っている | 今回の修正対象に近い |
アプリやデスクトップ更新時に-Tagを使っている | Az.DesktopVirtualization 6.0.0で失敗する可能性がある |
| 個人用ホストプールで複数デスクトップ割り当てを検討している | MultiplePersistent対応を確認する価値がある |
今回の更新は、AVD利用者全員に即時の作業を強制するものではありません。しかし、PowerShell自動化を使っている環境では、放置すると将来のAz更新時にスクリプトが止まる可能性があります。まずは-Tag依存の有無、登録トークン操作、ホストプール設定の3点を確認し、検証環境で新しいAz.DesktopVirtualizationの挙動を押さえてから本番展開へ進めるのが安全です。
コメント