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

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

アプリ接続の主な利点の一部を次に示します。

• アプリケーションは、RemoteApp を使用して、またはデスクトップ セッションの一部として配信されます。 アクセス許可はユーザーごとのアプリケーションごとに適用されるため、リモート セッションでユーザーがアクセスできるアプリケーションをより細かく制御できます。 デスクトップ ユーザーには、割り当てられたアプリ アタッチ アプリケーションのみが表示されます。

• 同じアプリケーション パッケージを複数のホスト プールで使用できます。

• アプリケーションは、アプリケーション パッケージと同じ Azure リージョン内の、Windows クライアントまたはサポートされている 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 最適化セッション ホストを備えたホスト プールでのみ実行されるようにすることができます。

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

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

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

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

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

ディスク イメージの種類

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

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

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

アプリケーションの登録

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

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

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

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

アプリケーションの状態

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

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

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

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

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

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

ID プロバイダー

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

ファイル共有

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

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 Virtual Desktop サービス プリンシパルに Azure RBAC ロールを割り当てる方法については、「Azure Virtual Desktop サービス プリンシパルに RBAC ロールを割り当てる」を参照してください。 今後の更新プログラムでは、Azure Virtual Desktop ARM プロバイダー サービス プリンシパルを割り当てる必要はなくなります。

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

  警告

  ストレージ アカウントに Azure Virtual Desktop ARM プロバイダー サービス プリンシパルを割り当てると、ストレージ アカウント内のすべてのデータに 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 を使用して、アクセス許可が正しいことを確認できます。 詳細については、「 ファイル共有アクセスの確認」を参照してください。

User and Deployment Configuration Files

アプリのアタッチを通じて配信される App-V パッケージの場合は、App-V 動的構成ファイルを使用して、アプリケーションの動作をカスタマイズできます。 アプリのアタッチは、予想される命名規則に従う標準構成ファイルを自動的に検出します。 これらのファイルがアプリのアタッチ パッケージと同じフォルダー内にあり、xml の前に App-V ファイルの名前が付けられている場合、これらのファイルは処理中にアプリケーション パッケージに自動的に関連付けられます。 ファイル パスが \share\folder\filename.appv の場合、以下の例が自動的に検出され、パッケージで使用されます。

• \share\folder\filename_UserConfig.xml

• \share\folder\filename_DeploymentConfig.xml

$a = Get-AzWvdAppAttachPackage -SubscriptionId blahblah -ResourceGroupName blahblahrg -Name contosoPackage

$dependencyType = $a.GetType().Assembly.GetTypes() |
    Where-Object {
        $_.Name -eq 'MsixPackageDependencies' -and
        $_.Namespace -like '*DesktopVirtualization*'
    } |
    Select-Object -First 1

$newDependency = [System.Activator]::CreateInstance($dependencyType)
$newDependency.DependencyName = "FilePathToUserConfig"
$newDependency.Publisher = "Group Object Id"
$newDependency.MinVersion = 1
$dependencyList = $a.ImagePackageDependency
$dependencyList += $newDependency
Update-AzWvdAppAttachPackage -ImagePackageDependency $dependencyList -SubscriptionId blahblah -ResourceGroupName blahblahrg -Name contosoPackage

# Remove logic
$a = Get-AzWvdAppAttachPackage -SubscriptionId blahblah -ResourceGroupName blahblahrg -Name contosoPackage
$dependencyList = $a.ImagePackageDependency
$dependencyList  = $dependencyList | where-Object {$_.DependencyName -ne "FilePathToUserConfig"}
Update-AzWvdAppAttachPackage -ImagePackageDependency $dependencyList -SubscriptionId blahblah -ResourceGroupName blahblahrg -Name contosoPackage
 

ユーザー構成ファイルはユーザー レベルで評価されるため、ユーザーごとに異なるアプリケーション設定を受け取ることができます。 対照的に、配置構成ファイルはコンピューター レベルで適用され、セッション ホスト上のすべてのユーザーによって共有されます。 現時点では、ユーザー構成はデスクトップ接続でのみサポートされ、リモート アプリ接続ではサポートされません。

高度なシナリオでは、同じアプリケーションに対して複数のユーザー構成ファイルが必要になる場合があります。 このような場合は、PowerShell を使用して、追加のユーザー構成ファイルをアプリケーション パッケージに明示的に関連付けられる必要があります。

アプリのアタッチは、依存関係オブジェクトをチェックします

• DependencyName フィールドで UserConfig.xml で終わるファイル パスが指定されている

• その構成を受け取る必要のある Microsoft Entra セキュリティ グループを識別する発行元フィールドが含まれています。 アプリ パッケージの [発行元] フィールドの値は、ターゲット セキュリティ グループの オブジェクト ID に設定する必要があります。

ログイン中に、App Attach はユーザーのグループ メンバーシップを評価し、関連付けられているグループに基づいて適切なユーザー構成を適用します。

管理者は、異なるユーザー集団で個別のアプリケーション設定が必要な場合にのみ、複数のユーザー構成ファイルを使用する必要があります。標準的な展開では、自動的に検出されたシングル ユーザー構成ファイルに引き続き依存することができます。

パフォーマンス

要件は、イメージに格納されているパッケージ化されたアプリケーションの数によって大きく異なる可能性があり、要件を理解するにはアプリケーションをテストする必要があります。 より大きなイメージの場合は、より多くの帯域幅を割り当てる必要があります。 次の表は、1 GB のイメージまたは 1 つのアプリケーションを含む 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 パッケージには、有効なコード署名証明書が必要です。 これらのパッケージをアプリ接続で使用するには、セッション ホストで証明書チェーン全体が信頼されていることを確認する必要があります。 コード署名証明書にはオブジェクト識別子 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:

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

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

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

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

次の手順

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