Azure Virtual Desktop Classic 廃止: ITの次のステップ

紹介

Azure Virtual Desktop (classic) の廃止は、レガシー接続サービスの喪失と、基盤となる Azure リソースの継続的な利用可能性との間に重要な区別を生み出します。移行期限を逃した IT チームにとって、この区別を理解することは、既存のインフラを不必要に置き換えることなく回復を計画するために不可欠です。この記事では、廃止が既存のリソースにとって何を意味するのか、クラシックデプロイメントを特定する方法、評価する価値のある移行オプション、サポートされているアプリケーション配信アーキテクチャを選択する方法について説明します。

Azure Virtual Desktop Classicが廃止されるとはどういう意味ですか？

マイクロソフトは2026年9月30日をもってAzure Virtual Desktop (classic)を正式に廃止しました。マイクロソフトの公式文書によれば、「クラシックサービスへの接続は廃止後にブロックされます。」したがって、廃止はAzure Virtual Desktop (classic)展開モデルを使用した仮想デスクトップおよびアプリケーションの管理に関連する特定のタイプのサービスに影響を与えます。

ただし、退職プロセスはAzure Resource Manager（ARM）を使用する最新のAzure Virtual Desktopには適用されません。したがって、古いリソースをまだ利用しているユーザーにとっての主な懸念は、以前に動作していたサービスへの接続を確立できないことです。したがって、ユーザーは古いリソース管理に特に注意を払う必要があります。リソース自体は退職日後に消えることはありません。

何が正確に引退されたのですか？

Azure Virtual Desktop (classic)、以前はWindows Virtual Desktopとして知られていたものは、専用のPowerShell cmdlets、API、およびサービスオブジェクトに基づく管理インフラストラクチャを持っていました。

現代のAzure Virtual Desktopとは異なり、クラシックホストプールとアプリケーショングループは統一されたAzureリソースマネージャーリソースとして定義されていませんでした。

今日、これらのコンポーネントはAzureリソース管理システムに組み込まれており、管理者はAzureロールベースのアクセス制御（RBAC）を適用し、Azureポータルを通じてサービスを管理し、デプロイメント自動化のための最新のインフラストラクチャコードパターンを使用することができます。

機能	AVDクラシック（廃止）	モダンAVD
管理	レガシーコントロールプレーン	Azure リソース マネージャー
Azure ポータル	限定的な統合	ネイティブ統合
アクセス制御	レガシーテナントロール	Azure RBAC
自動化	クラシックAPIとPowerShell	ARM、API、Az PowerShell
デスクトップとアプリの配信	接続がブロックされました	サポートされています
サービスステータス	退職した	サポートされています

退職は、単なる製品名の変更ではなく、基盤となるサービスアーキテクチャの変更を表しています。

モダンAzure仮想デスクトップはまだ機能していますか？

はい。最新のAzure Virtual Desktopはサポートされており、フルWindowsデスクトップ、マルチセッションプラットフォーム、およびRemoteAppを通じた個別アプリ配信を引き続き提供しています。

Azure Resource Manager (ARM) に統合されたホストプールをすでに使用している組織は、クラシックサービスの廃止の影響を受けません。

ITマネージャーは、クラシックAzure Virtual Desktopのサポート終了と、古いRemote Desktopクライアントのサポート終了の違いにも注意する必要があります。Windows用のRemote Desktopクライアント（MSI）は、2026年3月27日にパブリッククラウド環境のサポート終了を迎え、クラシックAzure Virtual Desktopでは2026年9月28日にサポート終了となる予定です。

ITチームはAzure Virtual Desktop Classicデプロイメントをどのように特定できますか？

最初のステップは、退役したアーキテクチャに依存している生産ワークロードがまだあるかどうかを特定することです。

これは、数年前に稼働を開始したシステムに特に重要であり、新しい管理者によって再取得されたり、現在のインフラストラクチャの文書で無視されたりしている可能性があります。

Azure Resource Manager統合を確認する

AzureポータルでAzure Virtual Desktopリソースを確認することから始めるべきです。最新のAzure Virtual Desktopデプロイメントでは、ホストプール、アプリケーショングループ、およびワークスペースがサブスクリプションおよびリソースグループ内のAzureリソースとして公開されます。それに対して、従来のデプロイメントでは、異なる方法で管理されるサービスオブジェクトを公開していました。

以下のAzure Virtual Desktop要素の存在は、従来のデプロイメントの強力な指標となります。

• クラシック Azure Virtual Desktop PowerShell モジュールを使用するホストプール
• クラシックサービステナントまたはクラシックサービスAPIへの歴史的な言及
• ARMリソースに対応するアプリケーショングループが不足しています
• 古いドキュメントを参照するセッションホスト仮想マシン

同時に、Azure ポータルにホスト プールがないことは、必ずしもクラシック デプロイメントの指標ではありません。問題をさらに分析する前に、ユーザーがどのサブスクリプション、Microsoft Entra テナント、およびロールベースのアクセス制御を持っているかを常に確認する必要があります。

レガシー管理ツールと依存関係のレビュー

デプロイメントスクリプトと自動化リポジトリは、補足的な証拠のソースとして機能する場合があります。

例えば、Microsoft.RDInfra.RDPowerShellの参照を含むスクリプトや、従来のテナントレベルの管理操作が存在する場合、環境が古い管理スタックで構成されていることを示唆しています。

現代の環境では、Azure Resource Manager統合管理インターフェイスと関連するAz PowerShellモジュールを活用します。

管理者は、影響を受ける可能性のあるホストプールに関連するすべてのアプリケーション、ユーザー、およびインフラストラクチャリソースを在庫管理する必要があります。

これには、セッションホストの仮想マシン、アプリケーションの割り当て、プロファイルの保存場所、認証の依存関係、ネットワーク構成、およびバックアップリポジトリの調査が含まれます。 Microsoft手動移行ドキュメント クラシックサービスオブジェクトモデルとAzure Resource Manager (ARM)統合リソースモデルとの詳細な比較が含まれています。

Azure Virtual Desktop Classicが終了した後、既存のリソースに何が起こる可能性がありますか？

最も重要な違いは、退役した接続サービスと基盤となるAzureインフラストラクチャの間にあります。

クラシックデスクトップ接続がブロックされている間、既存の仮想マシン、ストレージリソース、およびアプリケーションデータはそのまま残ることができます。

既存の仮想マシンとストレージは利用可能なままです

Azure仮想マシンは、退役したクラシックサービス制御プレーンに依存せずに独自に管理されるリソースです。したがって、サブスクリプション内で作成されたセッションホスト仮想マシン、管理ディスク、およびネットワークリソースはまだ存在する可能性があります。

ただし、退役した接続ブローカーを再設置するためには使用できません。新しいAzureインフラストラクチャで作成された仮想マシンは、組織のデスクトップエクスペリエンスを作業状態に戻すためには利用できません。

管理者は各リソースを慎重に確認し、サポートされている構成に再利用できる場合は、次の手順を実行する必要があります。

仮想マシンのオペレーティングシステムがサポートされているか、アプリケーションやセキュリティ設定が互換性があるかを確認することが重要です。

アプリケーションアクセスとユーザーデータには別々のチェックが必要です

クラシックデスクトップまたはRemoteAppセッションタイプを介して接続したユーザーは、もはやこのサービスを通じてアプリケーションを起動できなくなります。

サービスを終了する結果、デスクトップ、公開アプリケーションへのアクセスの喪失やビジネスプロセスの中断が生じる可能性があります。

ただし、サービスの終了はユーザー関連データが削除されることを保証するものではありません。

ほとんどの場合、ユーザーのデータはAzure Files、VMディスク、またはその他のストレージ媒体に保存される可能性がありますが、この情報の保持とアクセス可能性は、どのように構成され、権限で保護され、バックアップされているかに基づいています…

そのため、関与するシステムを廃止または移行する前に、IT部門は必要なすべてのデータを保存していることを確認する必要があります。

チームは、Azure Virtual Desktop Classicが退役した後でも移行できますか？

Microsoftは、Azure Virtual Desktop（クラシック）から新しいARM統合Azure Virtual Desktopへの移行パスを2つ文書化しています：自動移行と手動移行。

両方のオプションは2026年9月30日まで有効であることを意図していました。

その日付は過去のものであるため、管理者はドキュメントに記載されているツールをすべてのシナリオにおいて本番環境で使用可能と見なすべきではありません。

Microsoftのドキュメントは移行期間に関するガイダンスを提供していません。

したがって、組織は退職後の移行ツールやプロセスに依存すべきではありません。

オプション 1: 自動移行

マイクロソフトの自動移行プロセス PowerShellベースのツールを利用して、対象となるクラシックサービス構成をARMリソースに移行します。

会社のドキュメントでは、ユーザーが必要な権限を持つアクティブなAzureサブスクリプションを持ち、移行モジュールによって示された環境要件を満たすことを推奨しています。

例えば、Microsoftのガイドラインでは、ユーザーにAzureリソースを作成するための寄稿者権限と、アプリケーショングループのメンバーシップを管理するためのユーザーアクセス管理者権限を委任することが推奨されています。

ただし、ツールが退役後のデータ回復を保証できないことを認識することが重要です。

アクティブなクラシックデプロイメントを持つ組織は、マイクロソフトサポートに相談して、移行プロセスがその環境で利用可能なオプションであるかどうかを確認する必要があります。

オプション2：手動移行または再構築

手動移行には、最新のAzure Virtual Desktopリソースの作成とサービス構成の再構成が必要です。

特定のケースに応じて、管理者は次のことを行う必要がある場合があります：

• ARMベースのホストプール、アプリケーショングループ、ワークスペースを統合して作成する
• セッションホスト仮想マシンを設定または置き換えます
• 新しいホストプールで互換性のあるセッションホストを登録する
• ユーザーとアプリケーションの関連付けを再作成する
• アイデンティティ、ネットワーク、セキュリティ、およびプロファイルの設定を調整する

手動アプローチは、レガシー構成に文書化されていない複雑さや広範なカスタマイズが含まれている場合、または最新の移行ツールが不十分であることが証明された場合に必要になります。

特に、配信インフラストラクチャの再構築は、必ずしもアプリケーションやデータの完全な置き換えを伴うわけではありません。

残りのコンポーネントは、適切な互換性評価、ライセンス評価、およびセキュリティ監査を通じて再利用できることがよくあります。

現在の既存リソースの状態とMicrosoftからの利用可能なサポートに基づいて決定する必要があります。

状況	評価アプローチ
適格なクラシック構成とMicrosoftは移行サポートを確認します	自動移行
複雑またはアクセスできないクラシック構成	手動再構築
既存のVMとデータは利用可能なままです	配信サービスを再構築し、再利用を評価する
レガシー作業負荷はもはや必要ありません	安全な廃止
Azureホステッドデスクトップはもはや必要ありません	代替配信アーキテクチャ

ITチームは退職期限を逃した場合、何をすべきですか？

2026年9月30日までに移行を完了していない組織は、リソースの保護とビジネスアプリケーションへのアクセスの復元を優先するべきです。

退役したサービスへの複数の接続を試みる代わりに、管理者は回復プロセスを実行することをお勧めします。

ステップ 1: サービスへの影響を評価する

利用できないユーザー、デスクトップ、およびアプリケーションを特定します。

影響を受けているのが全体の環境なのか特定のワークロードなのかを確認してください。この問題が古典的なリタイアメントに関連していることを確認し、他の認証、ネットワーキング、またはセッションホストに関連する問題ではないことを確認してください。

ステップ2：インフラストラクチャとデータを保護する

Azure サブスクリプションをレビューして、現在の仮想マシン、管理ディスク、ストレージアカウント、およびネットワークリソースを特定します。

ドキュメントの依存関係を確認し、確保する バックアップ アクションを取る前に存在します。アプリケーションデータ、ユーザープロファイル、および構成情報が特定されるまでリソースを削除しないでください。

ステップ 3: Microsoft と回復オプションを確認する

Microsoftサポートに連絡して、まだサポートされている移行/回復手続きが利用可能であることを確認してください。

初期の自動/手動移行手順は、退職日を考慮して開発されたため、適用されるものと見なすべきではありません。

クラシック構成を移行できない場合は、サポートされているAzure Virtual Desktopリソースを使用して環境を再構築する必要があるかもしれません。

ステップ4：アプリケーションとデスクトップ配信の復元

ユーザーが必要とするアプリケーションやデスクトップをサポートするアーキテクチャを選択してください。

Azure Virtual Desktopに留まることを計画している組織にとって、通常はARM統合ホストプール、サポートされたセッションホスト、アプリケーショングループ、およびユーザー割り当ての設定が含まれます。

他の組織が見つけるかもしれません アプリケーションの公開 またはデスクトップソリューションが彼らのニーズにより適しています。

目標は、以前の設定の複雑さや不必要なオーバーヘッドを避けながら、アクセスを再確立することです。

Azure Virtual Desktopの移行を検証する方法は何ですか？

インフラストラクチャの復元は、通常のユーザー操作を保証するものではありません。

サービスおよびアプリケーションレベルで移行または再構築を検証する必要があります。

認証とユーザーアクセスの確認

ユーザーが認証し、割り当てられたリソースにアクセスできることを確認してください。

Microsoft Entra、マルチファクター認証、条件付きアクセス ポリシー、および適用される Azure RBAC 割り当てを確認してください。

管理者は、権限が最小特権の原則に沿っていることを確認し、意図せずに引き継がれた古いアクセスパターンがないことを確認する必要があります。

ビジネスクリティカルアプリケーションのテスト

異なる代表ユーザーアカウントを利用して、公開されたアプリケーションとデスクトップをテストします。

検証活動には、アプリケーションの起動、データベース接続、ネットワーク共有、印刷、クリップボードのリダイレクト、および必要な周辺機器が含まれるべきです。

レガシーアプリケーションは、特定のOS構成、ネットワークパス、またはアプリケーションコンポーネントを必要とする可能性があるため、特別な配慮が必要です。

レガシーアプリケーションの例としては、正常に起動するが新しいセッションホストからデータベースに接続できないERPアプリケーションが考えられます。

プロファイル、パフォーマンス、およびオペレーションを検証する

FSLogixやその他のプロファイリングツールを使用している企業は、すべてが正しく接続されていること、持続的であること、適切にアクセスできることを確認する必要があります。

初めてサインインして、ユーザーがアプリケーションを開いたときや次回のサインイン時にすべてが正常に動作するかどうかを確認することが重要です。また、プロセスが監視され、バックアップされ、復元されることを確認することも不可欠です。

移行は、すべてが準備完了し、ユーザーがアプリケーションにアクセスできるようになったときにのみ完了します。システムを適切に維持できる必要があります。

組織はデスクトップ配信アーキテクチャを再考すべきか？

Azure Virtual Desktop (classic) の退役は主にプラットフォームのライフサイクルに関する問題ですが、現在のデスクトップ配信プラットフォームがあなたのニーズを引き続きサポートしているかどうかを評価する機会も提供します。

現代のAzure Virtual Desktopへの移行は、多くの人々にとって明らかな選択肢であり、特にすでにAzureファーストでAzureホストのデスクトップを利用している人々にとってはそうです。

他の組織は、より複雑な要件が少ないです。

モダンAzure仮想デスクトップはいつ意味がありますか？

モダン Azure Virtual Desktop Azureでホストされる中央管理されたWindowsデスクトップとアプリを必要とする組織に適している可能性があります。

マルチセッション、RemoteAppモデル、Microsoft IDおよび管理ツールを有効にします。

既存のAzureの利用がある企業にとっては理にかなっていますが、IT部門は依然としてライセンス、ネットワーキング、ストレージ、管理、運用面など、クラウドの複雑さに対処しなければなりません。

別のWindowsアプリケーション公開アーキテクチャはいつ適切ですか？

すべての組織がMicrosoft Azureにホストされた完全に実装されたデスクトップ仮想化環境を必要とするわけではありません。

一部の企業は限られたものだけを必要としています。 リモートアクセス 特定のWindowsアプリケーション、例えば財務やERPアプリケーション、または従来の業務用アプリケーションに対して。

これらの組織は、一般的な仮想デスクトップインフラストラクチャ（VDI）を展開する代わりに、中央管理されたWindowsサーバーにホストされているアプリケーションを公開することを検討できます。

モダンAzure Virtual Desktopは、デスクトップやアプリケーションの仮想化だけでなく、アプリケーションの公開についても関係しています。

今日、RemoteApp方式を使用してAzureアプリケーションを公開することが可能です。

アプリケーション配信の分野には二項対立は存在せず、むしろアプリケーションの公開からデスクトップ仮想化までの連続体があるというのが現実です。

議論は、特定の組織とユースケースに最も関連性のあるアプリケーション配信アーキテクチャを見つけることに焦点を当てるべきです。

例えば、Windows Serverフォルダーにホストされている長期間使用されているアプリケーションが、一連の認可されたユーザーによってアクセスされている場合、レガシーインフラストラクチャが正常に機能している限り、組織はそれをAzure Virtual Desktopに公開する必要はありません。

その代わりに、そのような企業にとって、アプリケーションホスティングの場所をオンプレミスに残しながら、アプリケーションアクセス方法をアップグレードすることが有益かもしれません。

どの要因が決定を導くべきか？

IT部門は、廃止されたシステムの機能ではなく、展開ニーズに対する選択を評価する必要があります。

考慮	重要な質問
ホスティング	Azureでワークロードを実行する必要がありますか？
ユーザーエクスペリエンス	フルデスクトップまたは選択したアプリケーション？
互換性	既存のWindowsアプリケーションは動作しますか？
セキュリティ	アイデンティティとセッションアクセスはどのように保護されていますか？
管理	インフラストラクチャを維持しているのは誰ですか？
ライセンス	どのMicrosoftおよびソフトウェアライセンスが適用されますか？
スケーラビリティ	同時に必要なユーザー数は何ですか？
費用	総所有コストはどのくらいですか？

目的は、可用性、セキュリティ、および管理の複雑さを軽減する要件を満たす企業アーキテクチャを選択することです。

Windowsアプリケーションとデスクトップ配信の代替を探していますか？

現代のAzure Virtual Desktopへの移行は、すべての組織にとって必ずしも最良の選択肢ではありません。既存のWindowsアプリケーションや中央でホストされたデスクトップへのアクセスが主に必要な企業は、よりシンプルなアーキテクチャの恩恵を受ける可能性があります。特に、完全にAzureホストされた仮想デスクトップ環境を必要としない場合はなおさらです。

TSplus リモートアクセス ITチームがRDP互換クライアントまたはHTML5ウェブポータルを通じてWindowsアプリケーションと完全なリモートデスクトップを公開できるようにします。オンプレミスおよびクラウドホストされたWindowsサーバーをサポートしており、既存のアプリケーションを維持しながらリモートアプリケーション配信を簡素化したい組織にとって実用的な代替手段を提供します。

結論

Azure Virtual Desktop (classic) の退役により、影響を受けるデプロイメントを特定し、既存のリソースを保持し、サポートされているインフラストラクチャを通じてアクセスを復元することが不可欠です。IT チームは、移行または再構築を試みる前に、利用可能な回復オプションを確認する必要があります。

組織が最新のAzure Virtual Desktopを継続するか、別の配信アーキテクチャを採用するかにかかわらず、優先事項は不必要な運用の複雑さなしに、安全で信頼性のあるアプリケーションアクセスを確保することです。