Azure Virtual Desktop でのアプリアタッチ

App Attach を使用すると、アプリケーション パッケージから Azure Virtual Desktop のユーザー セッションにアプリケーションを動的にアタッチできます。 アプリケーションはセッション ホストまたはイメージにローカルにインストールされないため、セッション ホストのカスタム イメージを簡単に作成でき、organizationの運用オーバーヘッドとコストが削減されます。 アプリケーションはコンテナー内で実行され、ユーザー データ、オペレーティング システム、およびその他のアプリケーションが分離され、セキュリティが強化され、トラブルシューティングが容易になります。

App Attach の主な利点を次に示します。

• アプリケーションは、RemoteApp を使用して、またはデスクトップ セッションの一部として配信されます。 アクセス許可はユーザーごとにアプリケーションごとに適用され、ユーザーがリモート セッションでアクセスできるアプリケーションをより詳しく制御できます。 デスクトップ ユーザーには、割り当てられたアプリアタッチ アプリケーションのみが表示されます。
• 同じアプリケーション パッケージを複数のホスト プール間で使用できます。
• アプリケーションは、アプリケーション パッケージと同じ Azure リージョンで Windows クライアント オペレーティング システムを実行している任意のセッション ホストで実行できます。
• メンテナンス期間を必要とせずに、新しいディスク イメージを使用してアプリケーションを新しいアプリケーション バージョンにアップグレードできます。
• ユーザーは、同じセッション ホスト上で同じアプリケーションの複数のバージョンを同時に実行できます。
• 使用状況と正常性のテレメトリは、Azure Log Analytics を通じて利用できます。

次のアプリケーション パッケージの種類とファイル形式を使用できます。

MSIX と Appx は、Windows アプリケーションに最新のパッケージ化エクスペリエンスを提供する Windows アプリケーション パッケージ形式です。 アプリケーションはコンテナー内で実行され、ユーザー データ、オペレーティング システム、およびその他のアプリケーションが分離され、セキュリティが強化され、トラブルシューティングが容易になります。 MSIX と Appx は似ていますが、メイン違いは、MSIX が Appx のスーパーセットである点です。 MSIX では、Appx のすべての機能に加えて、エンタープライズでの使用に適したその他の機能がサポートされています。

Windows 用 Microsoft Application Virtualization (App-V) は、Win32 アプリケーションを仮想アプリケーションとしてユーザーに提供します。 仮想アプリケーションは、一元管理されたサーバーにインストールされ、リアルタイムで必要に応じてサービスとしてユーザーに配信されます。 ユーザーは、使い慣れたアクセス ポイントから仮想アプリケーションを起動し、ローカルにインストールされているかのように操作します。

ソフトウェア ベンダーから MSIX パッケージを取得することも、 既存のインストーラーから MSIX パッケージを作成することもできます。 MSIX の詳細については、「 MSIX とは」を参照してください。

ユーザーがアプリケーションを取得する方法

同じホスト プール内または同じセッション ホスト上の異なるユーザーに異なるアプリケーションを割り当てることができます。 サインイン中に、ユーザーが適切なタイミングで適切なアプリケーションを取得するには、次の 3 つの要件をすべて満たす必要があります。

• アプリケーションをホスト プールに割り当てる必要があります。 アプリケーションをホスト プールに割り当てると、アプリケーションが使用できるホスト プールを選択して、アプリケーションで適切なハードウェア リソースを使用できるようにすることができます。 たとえば、アプリケーションがグラフィックスを集中的に使用している場合は、GPU 最適化セッション ホストを含むホスト プールでのみアプリケーションを実行できます。

• ユーザーはホスト プール内のセッション ホストにサインインできる必要があるため、デスクトップまたは RemoteApp アプリケーション グループに存在する必要があります。 RemoteApp アプリケーション グループの場合、App Attach アプリケーションをアプリケーション グループに追加する必要がありますが、アプリケーションをデスクトップ アプリケーション グループに追加する必要はありません。

• アプリケーションをユーザーに割り当てる必要があります。 グループまたはユーザー アカウントを使用できます。

これらの要件がすべて満たされている場合、ユーザーはアプリケーションを取得します。 このプロセスでは、どのホスト プール上のアプリケーションを取得するか、また、1 つのホスト プール内のユーザー、または同じマルチセッション セッション ホストにサインインしたユーザーが異なるアプリケーションの組み合わせを取得する方法を制御できます。 要件を満たしていないユーザーは、アプリケーションを取得しません。

アプリケーション イメージ

Azure Virtual Desktop で MSIX アプリケーション パッケージを使用する前に、既存のアプリケーション パッケージから MSIX イメージを作成 する必要があります。 または、 代わりに App-V パッケージを使用することもできます。 その後、各 MSIX イメージまたは App-V パッケージを、セッション ホストがアクセスできるファイル共有に格納する必要があります。 ファイル共有の要件の詳細については、「ファイル 共有」を参照してください。

ディスク イメージの種類

MSIX ディスク イメージと Appx ディスク イメージの場合は、 複合イメージ ファイル システム (CimFS)、 VHDX、または VHD を使用できますが、 VHD の使用はお勧めしません。 CimFS イメージのマウントとマウント解除は、VHD および VHDX イメージよりも高速であり、CPU とメモリの消費も少なくなります。 アプリケーション イメージに CimFS を使用するのは、セッション ホストがWindows 11を実行している場合のみです。

CimFS イメージは、複数のファイルの組み合わせです。1 つのファイルには .cim ファイル拡張子があり、少なくとも 2 つの他のファイルと共にメタデータが含まれています。1 つは objectid_ で始まり、もう 1 つは実際のアプリケーション データを含む region_ で始まります。 .cimファイルに付随するファイルには、ファイル拡張子がありません。 次の表は、CimFS イメージ用に見つかるファイルの例の一覧です。

次の表は、VHDX と CimFS のパフォーマンス比較です。 これらの数値は、形式ごとに 300 MB の 500 ファイルを含むテスト実行の結果であり、 テストは DSv4 Azure 仮想マシンで実行されました。

アプリケーションの登録

App Attach は、サインイン中にファイル共有からユーザーのセッションにアプリケーションを含むディスク イメージまたは App-V パッケージをマウントした後、登録プロセスによってアプリケーションをユーザーが使用できるようになります。 登録には次の 2 種類があります。

• オンデマンド: アプリケーションはサインイン時にのみ部分的に登録され、アプリケーションの完全な登録は、ユーザーがアプリケーションを起動するまで延期されます。 オンデマンドは、Azure Virtual Desktop へのサインインにかかる時間には影響しないため、使用することをお勧めする登録の種類です。 オンデマンドは、既定の登録方法です。

• ログオン ブロック: ユーザーに割り当てる各アプリケーションが完全に登録されています。 登録は、ユーザーがセッションにサインインしている間に行われます。これは、Azure Virtual Desktop へのサインイン時間に影響する可能性があります。

App Attach では、ユーザーが使用できるアプリケーションの数は制限されません。 サポートできるユーザーまたはアプリケーションの数が制限される可能性があるため、使用可能なネットワーク スループットと、ファイル共有がサポートするファイルごとの開いているハンドルの数 (各イメージ) を考慮する必要があります。 詳細については、「 ファイル共有」を参照してください。

アプリケーションの状態

アプリケーション パッケージは、アクティブまたは非アクティブとして設定されます。 [アクティブ] に設定されたパッケージを使用すると、アプリケーションをユーザーが使用できるようになります。 Azure Virtual Desktop では、 非アクティブ に設定されたパッケージは無視され、ユーザーがサインインしても追加されません。

アプリケーションの新しいバージョン

新しいバージョンのアプリケーションを追加するには、更新されたアプリケーションを含む新しいイメージを指定します。 この新しいイメージは、次の 2 つの方法で使用できます。

• サイド バイ サイド: 新しいディスク イメージを使用して新しいアプリケーションを作成し、既存のアプリケーションと同じホスト プールとユーザーに割り当てます。

• インプレース: アプリケーションのバージョン番号が変更された新しいイメージを作成し、新しいイメージを使用するように既存のアプリケーションを更新します。 バージョン番号は大きくすることも低くすることもできますが、同じバージョン番号でアプリケーションを更新することはできません。 すべてのユーザーが使用を終了するまで、既存のイメージを削除しないでください。

更新後、ユーザーは次回サインインすると、更新されたアプリケーション バージョンを取得します。 ユーザーは、以前のバージョンの使用を停止して新しいバージョンを追加する必要はありません。

ID プロバイダー

App Attach で使用できる ID プロバイダーを次に示します。

ファイル共有

App Attach では、アプリケーション イメージが SMB ファイル共有に格納され、サインイン中に各セッション ホストにマウントされる必要があります。 App Attach には、ファイル共有で使用されるストレージ ファブリックの種類に依存しません。 Microsoft Entra IDまたはActive Directory Domain Servicesと互換性があり、コストと管理オーバーヘッドの間で優れた価値を提供するため、Azure Filesを使用することをお勧めします。

Azure NetApp Filesを使用することもできますが、セッション ホストをActive Directory Domain Servicesに参加させる必要があります。

次のセクションでは、ファイル共有に必要なアクセス許可、パフォーマンス、可用性に関するいくつかのガイダンスを提供します。

アクセス許可

各セッション ホストは、ファイル共有からアプリケーション イメージをマウントします。 各セッション ホスト コンピューター オブジェクトがファイルとファイル共有への読み取りアクセスを許可するように NTFS と共有のアクセス許可を構成する必要があります。 適切なアクセス許可を構成する方法は、ファイル共有とセッション ホストに使用しているストレージ プロバイダーと ID プロバイダーによって異なります。

• セッション ホストがMicrosoft Entra IDに参加したときにAzure Filesを使用するには、閲覧者とデータ アクセス Azure ロールベースのアクセス制御 (RBAC) ロールを Azure Virtual Desktop と Azure Virtual DesktopARM Provider サービス プリンシパルの両方に割り当てる必要があります。 この RBAC ロールの割り当てにより、セッション ホストはアクセス キーまたはMicrosoft Entraを使用してストレージ アカウントにアクセスできます。

• Azure Virtual Desktop サービス プリンシパルに Azure RBAC ロールを割り当てる方法については、「Azure Virtual Desktop サービス プリンシパルへの RBAC ロールの割り当て」を参照してください。 今後の更新では、 Azure Virtual Desktop ARM Provider サービス プリンシパルを割り当てる必要はありません。

  Microsoft Entra ID、Active Directory Domain Services、またはMicrosoft Entra Domain Servicesに参加しているセッション ホストでAzure Filesを使用する方法の詳細については、「Azure Filesの概要」を参照してください。SMB アクセス用の ID ベースの認証オプション。

  警告

  Azure Virtual Desktop ARM Provider サービス プリンシパルをストレージ アカウントに割り当てると、ストレージ アカウント内のすべてのデータに Azure Virtual Desktop サービスが付与されます。 アプリアタッチで使用するアプリのみをこのストレージ アカウントに保存し、アクセス キーを定期的にローテーションすることをお勧めします。

• Active Directory Domain ServicesでAzure Filesする場合は、ストレージ ファイル データ SMB 共有閲覧者 Azure ロールベースのアクセス制御 (RBAC) ロールを既定の共有レベルのアクセス許可として割り当て、NTFS アクセス許可を構成して各セッション ホストのコンピューター オブジェクトに読み取りアクセス権を付与する必要があります。

  Microsoft Entra ID、Active Directory Domain Services、またはMicrosoft Entra Domain Servicesに参加しているセッション ホストでAzure Filesを使用する方法の詳細については、「Azure Filesの概要」を参照してください。SMB アクセス用の ID ベースの認証オプション。

• Azure NetApp Filesでは、SMB ボリュームを作成し、NTFS アクセス許可を構成して、各セッション ホストのコンピューター オブジェクトに読み取りアクセス権を付与できます。 セッション ホストは、Active Directory Domain ServicesまたはMicrosoft Entra Domain Servicesに参加する必要があります。

アクセス許可が正しいことを確認するには、 PsExec を使用します。 詳細については、「 ファイル共有アクセスを確認する」を参照してください。

パフォーマンス

要件は、イメージに格納されているパッケージ化されたアプリケーションの数によって大きく異なる場合があり、要件を理解するためにアプリケーションをテストする必要があります。 大きなイメージの場合は、より多くの帯域幅を割り当てる必要があります。 次の表に、セッション ホストごとに 1 つのアプリケーションが必要とする 1 GB イメージまたは App-V パッケージの要件の例を示します。

アプリケーションのパフォーマンスを最適化するには、次のことをお勧めします。

• ファイル共有は、セッション ホストと同じ Azure リージョンに存在する必要があります。 Azure Filesを使用している場合は、ストレージ アカウントがセッション ホストと同じ Azure リージョンに存在する必要があります。

• 読み取り専用であるため、アプリケーションを含むディスク イメージをウイルス対策スキャンから除外します。

• ストレージとネットワーク ファブリックが適切なパフォーマンスを提供できることを確認します。 FSLogix プロファイル コンテナーで同じファイル共有を使用しないようにする必要があります。

Availability

Azure Virtual Desktop のディザスター リカバリー 計画には、セカンダリ フェールオーバーの場所へのファイル共有のレプリケートが含まれている必要があります。 また、ファイル共有パスがセカンダリの場所でアクセス可能であることを確認する必要もあります。 たとえば、分散ファイル システム (DFS) 名前空間とAzure Filesを使用して、異なるファイル共有間で 1 つの共有名を指定できます。 Azure Virtual Desktop のディザスター リカバリーの詳細については、「 ビジネス継続性とディザスター リカバリー計画を設定する」を参照してください。

Azure Files

Azure Filesには、ルート ディレクトリ、ディレクトリ、およびファイルごとの開いているハンドルの数に制限があります。 VHDX または CimFS ディスク イメージは、セッション ホストのコンピューター アカウントを使用してマウントされます。つまり、ユーザーごとにではなく、ディスク イメージごとにセッション ホストごとに 1 つのハンドルが開かれます。 制限とサイズ設定のガイダンスの詳細については、「スケーラビリティとパフォーマンスのターゲットのAzure Files」と「Azure Virtual Desktop のサイズ設定ガイダンスAzure Files」を参照してください。

MSIX および Appx パッケージ証明書

すべての MSIX パッケージと Appx パッケージには、有効なコード署名証明書が必要です。 App Attach でこれらのパッケージを使用するには、証明書チェーン全体がセッション ホストで信頼されていることを確認する必要があります。 コード署名証明書には、オブジェクト識別子 1.3.6.1.5.5.7.3.3があります。 パッケージのコード署名証明書は、次の場所から取得できます。

• パブリック証明機関 (CA)。

• Active Directory Certificate Services などの内部エンタープライズまたはスタンドアロンの証明機関。 秘密キーを含め、コード署名証明書をエクスポートする必要があります。

• 自己署名証明書を生成する PowerShell コマンドレット New-SelfSignedCertificate などのツール。 自己署名証明書は、テスト環境でのみ使用する必要があります。 MSIX および Appx パッケージの自己署名証明書の作成の詳細については、「 パッケージ署名用の証明書を作成する」を参照してください。

証明書を取得したら、証明書を使用して MSIX または Appx パッケージにデジタル署名する必要があります。 MSIX パッケージを作成するときに、MSIX パッケージ 化ツールを使用してパッケージに署名できます。 詳細については、「 任意のデスクトップ インストーラーから MSIX パッケージを作成する」を参照してください。

セッション ホストで証明書が信頼されるようにするには、セッション ホストが証明書チェーン全体を信頼する必要があります。 セッション ホストが証明書チェーンを信頼する方法は、証明書の取得元と、セッション ホストと使用する ID プロバイダーの管理方法によって異なります。 次の表に、セッション ホストで証明書が信頼されていることを確認する方法に関するガイダンスを示します。

• パブリック CA: パブリック CA からの証明書は、既定で Windows とWindows Serverで信頼されます。

• 内部エンタープライズ CA:

  • Active Directory に参加しているセッション ホストの場合、AD CS が内部エンタープライズ CA として構成され、既定で信頼され、Active Directory Domain Servicesの構成の名前付けコンテキストに格納されます。 AD CS がスタンドアロン CA として構成されている場合は、ルート証明書と中間証明書をセッション ホストに配布するようにグループ ポリシーを構成する必要があります。 詳細については、「グループ ポリシーを使用して Windows デバイスに証明書を配布する」を参照してください。

  • Microsoft Entra IDに参加しているセッション ホストの場合は、Microsoft Intuneを使用して、ルート証明書と中間証明書をセッション ホストに配布できます。 詳細については、「Microsoft Intuneの信頼されたルート証明書プロファイル」を参照してください。

  • ハイブリッド参加Microsoft Entra使用するセッション ホストの場合は、要件に応じて、前のいずれかの方法を使用できます。

• 自己署名: 信頼されたルートを各セッション ホストの 信頼されたルート証明機関 ストアにインストールします。 テストにのみ使用する必要があるため、グループ ポリシーまたはIntuneを使用してこの証明書を配布することはお勧めしません。

次の手順

Azure Virtual Desktop で App Attach アプリケーションを追加および管理する方法について説明します。