次の方法で共有

Azure Virtual Desktop のアプリ アタッチと MSIX アプリ アタッチ

  • [アーティクル]

Azure Virtual Desktop には、アプリケーション パッケージから Azure Virtual Desktop のユーザー セッションにアプリケーションを動的にアタッチできる機能が 2 つあります。それが、"アプリ アタッチ" と "MSIX アプリ アタッチ" です。 "アプリ アタッチ" と "MSIX アプリ アタッチ" のどちらの場合も、アプリケーションはセッション ホストまたはイメージにローカルにインストールされないため、セッション ホスト用のカスタム イメージの作成が簡単になり、組織の運用オーバーヘッドとコストが減ります。 アプリケーションはコンテナー内で実行され、ユーザー データ、オペレーティング システム、その他のアプリケーションが分離されるため、セキュリティが強化され、トラブルシューティングが容易になります。

次の表は、MSIX アプリのアタッチとアプリのアタッチを比べたものです。

MSIX アプリのアタッチ アプリ アタッチ
アプリケーションは、RemoteApp を使って、またはデスクトップ セッションの一部として配信されます。 アクセス許可はアプリケーション グループへの割り当てによって制御されますが、すべてのデスクトップ ユーザーには、デスクトップのアプリケーション グループ内にあるすべての MSIX アプリのアタッチ アプリケーションが表示されます。 アプリケーションは、RemoteApp を使って、またはデスクトップ セッションの一部として配信されます。 アクセス許可はユーザーごとにアプリケーション単位で適用され、ユーザーがリモート セッションでアクセスできるアプリケーションをより細かく制御できます。 デスクトップ ユーザーには、自分に割り当てられているアプリのアタッチ アプリケーションのみが表示されます。
アプリケーションは、1 つのホスト プールでのみ実行できます。 別のホスト プールで実行する場合は、別のパッケージを作成する必要があります。 同じアプリケーション パッケージを複数のホスト プールで使用できます。
アプリケーションは、それが追加されたホスト プールでのみ実行できます。 アプリケーションは、アプリケーション パッケージと同じ Azure リージョン内で Windows クライアント オペレーティング システムを実行している任意のセッション ホストで実行できます。
アプリケーションを更新するには、アプリケーションを削除し、別のバージョンのパッケージで作成し直す必要があります。 メンテナンス期間中にアプリケーションを更新する必要があります。 アプリケーションは新しいディスク イメージを使って新しいバージョンにアップグレードでき、メンテナンス期間は必要ありません。
ユーザーは、同じアプリケーションの 2 つのバージョンを、同じセッション ホスト上で実行することはできません。 ユーザーは、同じアプリケーションの 2 つのバージョンを、同じセッション ホスト上で同時に実行できます。
使用状況と正常性のテレメトリは、Azure Log Analytics を通じて利用することはできません。 使用状況と正常性のテレメトリは、Azure Log Analytics を通じて利用できます。

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

パッケージの種類 ファイル形式 機能の利用可能性
MSIX と MSIX バンドル .msix
.msixbundle		 MSIX アプリのアタッチ
アプリのアタッチ
Appx と Appx バンドル .appx
.appxbundle		 アプリのアタッチのみ
App-V .appv アプリのアタッチのみ

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

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

ヒント

この記事の先頭にあるボタンを選んで、"アプリ アタッチ" と "MSIX アプリ アタッチ" のどちらかを選び、関連するドキュメントをご覧ください。

ソフトウェア ベンダーから MSIX パッケージを入手することも、既存のインストーラーから MSIX パッケージを自分で作成することもできます。 詳しくは、「MSIX とは」をご覧ください。

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

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

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

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

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

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

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

同じホスト プール内の異なるユーザーに、異なるアプリケーションを割り当てることができます。 MSIX アプリのアタッチでは、MSIX パッケージをホスト プールに追加し、デスクトップまたは RemoteApp アプリケーション グループを使ってアプリケーションの割り当てを制御します。 サインイン時に、ユーザーが適切なタイミングで適切なアプリケーションを取得するには、次の要件が満たされている必要があります。

  • ユーザーはホスト プール内のセッション ホストにサインインできる必要があるため、ユーザーはデスクトップまたは RemoteApp アプリケーション グループに含まれる必要があります。

  • MSIX イメージがホスト プールに追加されている必要があります。

これらの要件が満たされている場合、ユーザーはアプリケーションを取得します。 デスクトップ アプリケーション グループを使って割り当てられたアプリケーションは、ユーザーのスタート メニューに追加されます。 要件を満たしていないユーザーは、アプリケーションを取得しません。

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

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

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

ディスク イメージの種類

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

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

ファイル名 サイズ
MyApp.cim 1 KB
objectid_b5742e0b-1b98-40b3-94a6-9cb96f497e56_0 27 KB
objectid_b5742e0b-1b98-40b3-94a6-9cb96f497e56_1 20 KB
objectid_b5742e0b-1b98-40b3-94a6-9cb96f497e56_2 42 KB
region_b5742e0b-1b98-40b3-94a6-9cb96f497e56_0 428 KB
region_b5742e0b-1b98-40b3-94a6-9cb96f497e56_1 217 KB
region_b5742e0b-1b98-40b3-94a6-9cb96f497e56_2 264,132 KB

次の表は、VHD と CimFS のパフォーマンスを比較したものです。 これらの数値は、それぞれの形式について 300 MB のファイル 500 個を使って行ったテスト実行の結果であり、テストは DSv4 Azure 仮想マシンで実行されました。

メトリック VHD CimFS
平均マウント時間 356 ミリ秒 255 ミリ秒
平均マウント解除時間 1615 ミリ秒 36 ミリ秒
メモリ消費量 6% (8 GB 中) 2% (8 GB 中)
CPU (スパイクのカウント) 複数回限界に達する 効果なし

アプリケーションの登録

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

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

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

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

重要

MSIX と Appx のすべてのアプリケーション パッケージに証明書が含まれています。 証明書がご使用の環境で信頼されていることを確認する必要があります。 自己署名証明書は、適切な信頼チェーンでサポートされています。

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

重要

すべての MSIX アプリケーション パッケージには証明書が含まれています。 証明書がご使用の環境で信頼されていることを確認する必要があります。 自己署名証明書はサポートされています。

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

アプリケーションの状態

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

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

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

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

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

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

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

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

MSIX アプリのアタッチでは、アプリケーション パッケージを削除してから、新しいディスク イメージを使って新しいアプリケーションを作成し、同じホスト プールにそれを割り当てる必要があります。 アプリのアタッチと同じようにインプレースで更新することはできません。 ユーザーは、次のサインイン時に、更新されたアプリケーションを含む新しいイメージを取得します。 これらのタスクは、メンテナンス期間中に実行する必要があります。

ID プロバイダー

アプリのアタッチで使用できる ID プロバイダーを次に示します。

ID プロバイダー Status
Microsoft Entra ID サポートされています
Active Directory Domain Services (AD DS) サポートされています
Microsoft Entra Domain Services サポートされていません

MSIX アプリのアタッチで使用できる ID プロバイダーを次に示します。

ID プロバイダー Status
Microsoft Entra ID サポートされていません
Active Directory Domain Services (AD DS) サポートされています
Microsoft Entra Domain Services (Azure AD DS) サポートされていません

ファイル共有

アプリのアタッチでは、アプリケーション イメージは SMB ファイル共有に格納されている必要があり、それはサインイン時に各セッション ホストにマウントされます。 アプリのアタッチは、ファイル共有で使われている記憶域ファブリックの種類に依存しません。 Microsoft Entra ID または Active Directory Domain Services と互換性があり、コストと管理オーバーヘッドに関して大きな価値が得られるため、Azure Files を使うことをお勧めします。

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

MSIX アプリのアタッチでは、アプリケーション イメージは SMB バージョン 3 のファイル共有に格納されている必要があり、それはサインイン時に各セッション ホストにマウントされます。 MSIX アプリのアタッチは、ファイル共有が使用する記憶域ファブリックの種類には依存していません。 MSIX アプリのアタッチに使用できるサポートされている ID プロバイダーと互換性があり、コストと管理オーバーヘッドに関して大きな価値が得られるため、Azure Files を使うことをお勧めします。 Azure NetApp Files を使うこともできますが、そのためにはセッション ホストを Active Directory Domain Services に参加させる必要があります。

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

アクセス許可

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

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

  • Azure RBAC の役割を Azure Virtual Desktop サービス プリンシパルに割り当てる方法については、「Azure Virtual Desktop サービス プリンシパルに RBAC ロールを割り当てる」をご覧ください。 今後の更新で、Azure Virtual Desktop ARM プロバイダーのサービス プリンシパルを割り当てる必要がなくなります。

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

    警告

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

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

PsExec を使って、アクセス許可が正しいことを確認できます。 詳しくは、「ファイル共有のアクセスを確認する」をご覧ください。

パフォーマンス

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

リソース 必要条件
安定状態での IOPS 1 つの IOP
コンピューターのブート サインイン 10 IOPS
待機時間 400 ミリ秒

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

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

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

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

可用性

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

Azure Files

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

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

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

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

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

  • 自己署名証明書を生成する 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 でアプリのアタッチ アプリケーションを追加して管理する方法を確認します。