2026年6月17日、Microsoft Tech CommunityのAzure Virtual Desktopフォーラムに「Windows OS edition validation error」という投稿が公開されました。結論として、これはAzure Virtual Desktopの新機能や仕様変更を告知するリリースノートではありません。Windows 11 Enterprise multi-sessionのセッションホストで、winver.exeとレジストリのOS名が一致しない事象についてのコミュニティ投稿です。
この情報だけを根拠に、設定変更、追加料金、強制移行が発生したとは判断できません。管理者が確認すべきなのは、レジストリのProductNameだけでOSを判定していないか、ホストプールに適したイメージを使っているか、カスタムイメージが正しく一般化されているかです。なお、投稿に登場するWindows 11 Enterprise multi-session 22H2は、すでにサポート期間が終了しています。該当環境では表示不一致の調査と並行して、サポート中のOSイメージへの移行を進める必要があります。(TECHCOMMUNITY.MICROSOFT.COM)
Azure TechCommunityの「Windows OS edition validation error」で確認された内容
投稿者の環境では、同じAzure Virtual Desktopセッションホストについて、次のように異なる情報が表示されていました。
winver.exe：Windows 11 multi-session 22H2- レジストリの
ProductName：Windows 10 multi-session
確認されたレジストリパスは次のとおりです。
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion問題になっている値はProductNameです。Windows 11を実行していても、この値にWindows 10と表示される事例は以前から報告されています。そのため、ProductNameだけを根拠に「Windows 10がインストールされている」「OSイメージが壊れている」と判断するのは適切ではありません。(TECHCOMMUNITY.MICROSOFT.COM)
今回の情報を変更点として整理すると、次のようになります。
| 確認項目 | 2026年6月17日時点の整理 |
|---|---|
| 公開された内容 | Azure Virtual DesktopフォーラムのコミュニティQ&A |
| Azureの仕様変更 | この投稿では発表されていない |
| 新しい必須設定 | なし |
| 追加料金 | なし |
| 専用の対応期限 | なし |
| 実務上の注意点 | ProductNameだけでOSを判定しない |
| 優先して確認する環境 | カスタムイメージ、OS判定スクリプト、Windows 11 22H2環境 |
Microsoft Learnの「Azure Virtual Desktopの新機能」では、2026年6月の変更としてコンテキストベースのリダイレクトが案内されていますが、OSエディション検証の仕様変更は掲載されていません。したがって、今回の投稿は製品変更の告知ではなく、個別環境のトラブルシューティング情報として扱うのが妥当です。(Microsoft Learn)
表示の不一致と実際の検証エラーを分けて考える
「Windows OS edition validation error」を調査するときは、次の2つを混同しないことが重要です。
レジストリの表示だけが異なるケース
winver.exeではWindows 11と表示され、レジストリのProductNameだけがWindows 10になっているケースです。
Azureでエラーが発生しておらず、セッションホストが正常に登録・稼働しているなら、表示上の不一致である可能性があります。この場合、レジストリを手作業でWindows 11に書き換える必要はありません。値を書き換えても、実際のOSエディションやライセンス、Azure MarketplaceイメージのSKUは変更されないためです。
修正すべきなのはOSではなく、ProductNameだけを参照している資産管理ツールや判定スクリプトです。
Azureのデプロイや登録で実際にエラーが出るケース
次のような場面でエラーが表示される場合は、イメージや構成の問題を調査します。
- ホストプール作成時
- セッションホスト追加時
- カスタムイメージからのVM作成時
- セッションホストの登録時
- 自動更新やセッションホスト構成の適用時
この場合は、エラーメッセージ、発生した処理、利用したイメージ、ホストプールの種類をセットで確認してください。
影響を受けやすいユーザーと管理者
今回の事象は、一般利用者よりもAzure Virtual Desktopの管理者や運用担当者に影響します。
| 対象 | 想定される影響 |
|---|---|
| 一般ユーザー | セッションホストが正常なら基本的に対応不要 |
| AVD管理者 | イメージ選択やOSエディション判定の見直しが必要 |
| カスタムイメージ管理者 | ベースOS、Sysprep、イメージバージョンの確認が必要 |
| 資産管理担当者 | ProductNameだけを使うOS判定が誤分類につながる |
| 自動化担当者 | PowerShellや監視ツールの判定条件を修正する可能性がある |
特に注意したいのは、レジストリの文字列を使ってWindows 10とWindows 11を振り分けている環境です。誤判定によって、更新リング、セキュリティポリシー、アプリ配布対象などが意図しないグループに割り当てられる可能性があります。
Windows OS edition validation errorの確認手順
実際のエラーが発生しているか確認する
最初に、単なる表示不一致なのか、Azure上で処理が失敗しているのかを切り分けます。
Azureポータルで次を確認してください。
- Azure Virtual Desktopの「セッションホスト」に警告やエラーがないか
- VMがホストプールに登録されているか
- リソースグループの「デプロイ」に失敗がないか
- Azure Activity Logに検証エラーが記録されていないか
- Log Analyticsを利用している場合は、セッションホスト作成履歴に失敗がないか
エラーがある場合は、エラーコード、対象リソース、発生時刻、Correlation IDを控えます。「OS edition validation error」という概要だけでなく、詳細メッセージまで保存することが重要です。
セッションホスト内でOS情報を確認する
管理者権限のPowerShellまたはコマンドプロンプトで、複数の情報源を比較します。
Get-CimInstance Win32_OperatingSystem |
Select-Object Caption, Version, BuildNumber, OSArchitectureGet-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion' |
Select-Object ProductName, EditionID, DisplayVersion, CurrentBuildNumber, UBRエディションはDISMでも確認できます。
dism /online /Get-CurrentEdition確認時は、次の項目をセットで記録してください。
- OSのCaption
- ビルド番号
DisplayVersionEditionID- DISMで取得した現在のエディション
winver.exeの表示内容
ProductNameだけがWindows 10で、ビルド番号やエディションがWindows 11 Enterprise multi-sessionとして整合しているなら、表示文字列だけの問題である可能性が高くなります。
デプロイ元のイメージを確認する
Azureポータルで対象VMを開き、イメージ情報を確認します。Azure CLIを利用できる場合は、次のコマンドでも取得できます。
az vm show \
--resource-group <リソースグループ名> \
--name <VM名> \
--query "storageProfile.imageReference" \
--output jsonMarketplaceイメージでは、主に次の値を確認します。
publisherofferskuversion
Azure Compute Galleryのカスタムイメージでは、次を確認してください。
- イメージ定義
- イメージバージョン
- 元になったMarketplaceイメージ
- OSの種類とエディション
- 作成日と最終更新日
- Sysprepの実行状況
ホストプール内のセッションホストは、利用者の体験や更新状態を揃えるため、原則として同じイメージ系列から展開します。
ホストプールとOSイメージの組み合わせを確認する
Microsoftは、プール型ホストプールではWindows 10またはWindows 11 Enterprise multi-session、もしくはWindows Serverの利用を推奨しています。個人用ホストプールでは、Windows 10またはWindows 11 Enterpriseが推奨されています。(Microsoft Learn)
Azure Virtual Desktopでサポートされる主なクライアントOSは次のとおりです。
- Windows 11 Enterprise multi-session
- Windows 11 Enterprise
- Windows 10 Enterprise multi-session
- Windows 10 Enterprise
一方、32ビットOS、N・KN・LTSCなど公式の対応表に含まれないエディション、Arm64ベースのAzure VMなどは、セッションホストとしてサポートされません。(Microsoft Learn)
原因別の対処方法
| 原因 | 見分け方 | 対処 |
|---|---|---|
ProductNameだけが異なる | Azure処理は成功し、ビルドとエディションが正常 | レジストリを変更せず、判定スクリプトを修正 |
| 利用目的に合わないOSイメージ | ホストプールの用途とイメージSKUが不一致 | サポートされるMarketplaceイメージから再展開 |
| Pro、Homeなど対象外のエディション | DISMやイメージSKUで判明 | Enterprise系の対応イメージに置き換える |
| カスタムイメージの一般化不備 | Marketplaceイメージでは成功し、カスタムイメージだけ失敗 | 新しいベースVMでSysprepを実行し、再キャプチャ |
| 古いOSバージョン | DisplayVersionが22H2など | サポート中のイメージへ更新・移行 |
| イメージ管理の不整合 | 同一ホストプール内で複数世代が混在 | イメージバージョンと展開手順を統一 |
Marketplaceイメージで切り分ける
カスタムイメージを使用している場合は、同じホストプール条件で、クリーンなWindows 11 Enterprise multi-sessionのMarketplaceイメージを使ってテストします。
Marketplaceイメージでは成功し、カスタムイメージで失敗するなら、原因を次の範囲に絞り込めます。
- ベースOSのエディション
- Sysprepの実行失敗
- イメージへの不要なAVD Agent登録
- ドメイン参加状態
- セキュリティ製品やアプリによるSysprep阻害
- 古いイメージバージョンの参照
Tech Communityの返信でも、Marketplaceイメージとカスタムイメージを比較する方法が、切り分け手段として案内されています。ただし、返信者はMicrosoftの製品リリース担当ではなくコミュニティ参加者であるため、最終的な対応可否はMicrosoft Learnの対応OS一覧と実際のエラー内容で判断してください。(TECHCOMMUNITY.MICROSOFT.COM)
カスタムイメージを作り直す
カスタムイメージを再作成するときは、次の流れで進めます。
- 対応するMarketplaceイメージから新しいベースVMを作る
- Windows Updateと必要なアプリを適用する
- アプリの動作とSysprep対応状況を確認する
- ベースVMをホストプールへ登録しない
- 必要に応じてドメインから離脱する
- Sysprepで一般化してシャットダウンする
- Azure Compute Galleryへ新しいバージョンとして登録する
- テスト用セッションホストで検証する
- 問題がなければ本番ホストを段階的に置き換える
Sysprepの基本コマンドは次のとおりです。
sysprep.exe /generalize /shutdownMicrosoftは、すでにホストプールへ登録したVMをゴールデンイメージとしてキャプチャしないよう案内しています。登録情報や期限切れトークンが残ると、新しいセッションホストがホストプールへ正常に参加できないことがあります。(Microsoft Learn)
Windows 11 Enterprise multi-session 22H2は移行を優先する
元の投稿に登場するWindows 11 Enterprise multi-session 22H2は、Microsoftのライフサイクル上、2025年10月14日にサポートを終了しています。Enterprise multi-sessionもWindows 11 Enterprise and Educationのライフサイクル対象です。(Microsoft Learn)
22H2を使用している場合、レジストリ表示の修正よりも、次の対応を優先してください。
- サポート中のWindows 11 Enterprise multi-sessionイメージを選定する
- 業務アプリ、Teams、FSLogix、セキュリティ製品を検証する
- 新しいイメージからテスト用セッションホストを展開する
- 本番ホストをドレインモードにして接続を停止する
- 利用者セッションがなくなったホストから順次置き換える
- 問題発生時に戻せるよう、旧イメージを一定期間保持する
Windows Enterprise multi-sessionには機能更新プログラムを適用できます。ただし、イメージベースで管理するプール型環境では、稼働中の全VMを個別に更新するより、新しい検証済みイメージからセッションホストを入れ替える方が、構成を統一しやすくロールバックも容易です。
また、Windows 10からWindows 11へのプール型セッションホストのインプレースアップグレードはサポートされません。Windows EnterpriseまたはProfessionalからmulti-sessionへ、プロダクトキーの変更だけで切り替えることもできないため、必要なエディションのイメージから再展開します。(Microsoft Learn)
設定・更新・移行・料金・期限の確認ポイント
| 項目 | 確認すべき内容 |
|---|---|
| 設定 | ProductNameだけを参照する判定処理がないか |
| 更新 | OSバージョンがサポート期間内か |
| 移行 | 新しいイメージでのテスト、ドレイン、段階的なホスト交換 |
| 料金 | 新しい料金は追加されていない |
| 期限 | 投稿固有の期限はないが、OSのサポート期限は確認が必要 |
| ライセンス | 利用者とOSに適したAVDアクセス権があるか |
今回の投稿による料金変更はありません。Azure Virtual Desktopの費用は、引き続きユーザーのアクセス権と、VM・ストレージ・ネットワークなどのAzureインフラストラクチャ費用に分かれます。組織内ユーザーは対象となるMicrosoft 365またはWindowsライセンス、外部顧客向けの商用提供では利用条件に応じてユーザー単位のアクセス料金を確認します。(Microsoft Learn)
対応時に失敗しやすいポイント
ProductNameをWindows 11に直接書き換える
表示は変えられても、OSの実体、エディション、AzureイメージSKUは変わりません。根本的な解決にならないため避けてください。
エラー内容を保存せずVMを作り直す
再現条件が失われ、原因がイメージ、ネットワーク、権限、登録処理のどこにあったのか分からなくなります。作り直す前にActivity Logとデプロイエラーを保存します。
稼働中のセッションホストをそのままイメージ化する
AVD Agentの登録情報や端末固有情報が残り、複製したVMが正常に登録されない原因になります。専用のベースVMを用意してください。
本番ホストを一斉に更新する
アプリやプロファイルに問題が出た場合、全利用者へ影響します。少数のテストホスト、検証用アプリケーショングループ、段階展開の順で進めます。
管理者が次に実施すること
まず、Azure上で実際の検証エラーが発生しているかを確認し、エラー詳細を保存してください。次に、winver.exe、CIM、DISM、レジストリを使って、ビルド番号とエディションを比較します。
ProductNameだけがWindows 10で、ほかの情報がWindows 11 Enterprise multi-sessionとして整合している場合は、OSを変更するのではなく、監視・資産管理スクリプトの判定方法を見直します。
エディションやイメージが不適切な場合は、対応するMarketplaceイメージで動作を切り分け、カスタムイメージを新しいバージョンとして再作成します。Windows 11 22H2を使用している環境では、表示不一致の有無にかかわらず、サポート中のイメージへ移行する計画を優先してください。
コメント