App Attach 讓你能動態將應用程式套件中的應用程式連接到 Azure 虛擬桌面中的使用者會話。 應用程式不會在會話主機或映像檔上本地安裝，這讓建立自訂會話主機的映像檔更容易，並降低組織的營運負擔與成本。 應用程式運行於容器中，容器將使用者資料、作業系統及其他應用程式分離，提升安全性並使故障排除更為容易。
以下是 App Attach 的一些主要優點：
應用程式可透過 RemoteApp 或桌面工作階段交付。 權限是每個應用程式、每個使用者都套用的，讓你能更精確地控制使用者在遠端工作階段中能存取哪些應用程式。 桌面用戶只會看到分配給他們的應用程式附著。
同一應用程式套件可在多個主機池間使用。
應用程式可在與該應用程式套件相同的 Azure 區域內，任何運行 Windows 用戶端或支援 Windows 伺服器作業系統的會話主機上執行。
應用程式可以升級到新的應用程式版本，並擁有新的磁碟映像檔，無需維護視窗。
使用者可以在同一台會議主機上同時執行同一應用程式的多個版本。
使用與健康相關的遙測資料可透過 Azure Log Analytics 提供。
您可以使用以下應用程式套件類型與檔案格式：
| 封裝類型 | 檔案格式 |
|---|---|
| MSIX 與 MSIX 套件 | .msix.msixbundle |
| Appx 與 Appx 組合包 | .appx.appxbundle |
| App-V | .appv |
MSIX 和 Appx 是 Windows 應用程式套件格式，為 Windows 應用程式提供現代化的打包體驗。 應用程式運行於容器中，容器將使用者資料、作業系統及其他應用程式分離，提升安全性並使故障排除更為容易。 MSIX 與 Appx 類似，主要差異在於 MSIX 是 Appx 的超集。 MSIX 支援 Appx 的所有功能，以及其他使其更適合企業使用的特性。
Microsoft 應用程式虛擬化 (App-V) for Windows 將 Win32 應用程式以虛擬應用程式的形式提供給使用者。 虛擬應用程式安裝於集中管理的伺服器上，並以即時及按需提供給使用者的服務。 使用者從熟悉的基地台啟動虛擬應用程式，並與它們互動，彷彿它們已安裝在本地。
你可以從軟體廠商取得 MSIX 套件，或 是從現有安裝程式建立 MSIX 套件。 欲了解更多 MSIX ，請參閱 What is MSIX？。
使用者如何取得應用程式
你可以在同一主機池或同一會話主機上，將不同的應用程式指派給不同的使用者。 登入時，使用者必須符合以下三項條件，才能在正確的時間取得正確的應用程式：
應用程式必須分配到主機池。 將應用程式指派到主機池，可以讓你有選擇性地選擇該應用程式可用的主機池，確保應用程式能使用正確的硬體資源。 例如，如果應用程式需要大量圖形，你可以確保它只在擁有 GPU 優化會話主機的主機池上執行。
使用者必須能夠在主機池中登入會話主機，因此他們必須在桌面或遠端應用程式群組中。 對於 RemoteApp 應用程式群組，必須將 App Attach 應用程式加入應用程式群組，但你不需要將該應用程式加入桌面應用程式群組。
應用程式必須被指派給使用者。 你可以使用群組或使用者帳號。
若符合所有這些要求，使用者即可取得該應用程式。 此流程可控制誰能在哪個主機池獲得應用程式，並說明單一主機池內的使用者，甚至登入同一多會話主機時，如何取得不同的應用程式組合。 不符合需求的使用者無法取得應用程式。
應用程式映像檔
在你能在 Azure 虛擬桌面中使用 MSIX 應用程式套件之前，你需要從現有的應用程式套件建立一個 MSIX 映像檔。 或者，你也可以使用 App-V 套件。 接著你需要將每個 MSIX 映像檔或 App-V 套件儲存在一個檔案分享中，讓你的會話主機能夠存取。 欲了解更多檔案分享的要求，請參閱 檔案共享。
磁碟映像類型
對於 MSIX 和 Appx 磁碟映像檔，你可以使用 CimFS) 、 VHDX 或 VHD (複合影像檔案系統，但我們不建議使用 VHD。 掛載與卸載 CimFS 映像比 VHD 和 VHDX 影像更快，且消耗的 CPU 和記憶體也更少。 我們只建議在你的會話主機執行 Windows 11 時，使用 CimFS 來管理應用程式映像檔。
CimFS 映像檔是由多個檔案組合而成：其中一個檔案具有副檔名並.cim包含元資料，另外至少還有兩個檔案，一個以開頭，另一個以開頭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 |
下表為 VHDX 與 CimFS 的效能比較。 這些數字是基於對 500 個檔案，每個格式 300 MB 的測試結果，測試是在 DSv4 Azure 虛擬機器上進行的。
| 計量 | VHD | CimFS |
|---|---|---|
| 平均騎乘時間 | 356毫秒 | 255毫秒 |
| 平均下馬時間 | 1615毫秒 | 36毫秒 |
| 記憶體耗用量 | 8 GB) (的 6% | 8 GB 的 2% () |
| CPU (計數尖峰) | 多次滿級 | 無效果 |
申請註冊
App Attach 會在使用者登入時，將包含應用程式的磁碟映像檔或 App-V 套件從檔案分享掛載到使用者的工作階段，然後透過註冊程序讓應用程式可供使用者使用。 登記有兩種類型：
隨需：應用程式在登入時僅部分註冊，完整註冊會延後至使用者啟動應用程式。 我們建議您使用隨選註冊，因為它不影響登入 Azure 虛擬桌面所需的時間。 隨選是預設的註冊方式。
登入封鎖：你指派給使用者的每個應用程式都是完全註冊的。 註冊會在使用者登入會話時進行，這可能會影響 Azure 虛擬桌面的登入時間。
重要事項
所有 MSIX 與 Appx 應用程式套件皆包含憑證。 你有責任確保這些憑證在你的環境中是可信的。 自簽憑證在適當的信任鏈中得到支援。
App Attach 並不限制使用者能使用的應用程式數量。 你應該考慮可用的網路吞吐量，以及每個檔案 (檔案) 支援的開放句柄數量，因為這可能會限制你能支援的使用者或應用程式數量。 欲了解更多資訊，請參閱 檔案分享。
應用狀態
應用程式套件會被設定為 啟用 或 非啟用。 將套件設為啟用時，應用程式會對使用者開放。 Azure 虛擬桌面會忽略設定為非活躍的套件，且使用者登入時不會被加入。
應用程式的新版本
您可以透過提供包含更新應用程式的新映像檔來新增應用程式版本。 你可以用這張新圖片做兩種用途：
並排：使用新的磁碟映像建立新應用程式，並將其指派給與現有應用程式相同的主機池和使用者。
原地：建立一個新的映像檔，應用程式的版本號會改變，然後更新現有應用程式以使用新的映像檔。 版本號可以高或低，但你不能更新同一個版本號的應用程式。 在所有使用者都使用完之前，不要刪除現有圖片。
更新後，使用者下次登入時會收到更新後的應用程式版本。 使用者不需要停止使用舊版本就能新增新版本。
身份提供者
以下是你可以使用 App Attach 使用的身份提供者：
| 身份提供者 | 狀態 |
|---|---|
| Microsoft Entra ID | 支援 |
| Active Directory Domain Services (AD DS) | 支援 |
| Microsoft Entra Domain Services | 不支援 |
檔案共用
App Attach 要求你的應用程式映像檔必須儲存在 SMB 檔案分享中，然後在登入時掛載到每個會話主機上。 App Attach 不會依賴檔案分享所使用的儲存結構類型。 我們建議使用 Azure 檔案儲存體，因為它相容於 Microsoft Entra ID 或 Active Directory 網域服務，且在成本與管理負擔間提供了極佳的價值。
你也可以使用 Azure NetApp Files，但那需要你的會話主機加入 Active Directory 網域服務。
以下章節將提供關於檔案分享所需權限、效能及可用性的指引。
權限
每個會話主機會從檔案分享掛載應用程式映像檔。 你需要設定 NTFS 和分享權限，讓每個會話主機物件都能讀取檔案和檔案分享。 你如何設定正確的權限，取決於你使用的是哪個儲存提供者和身份提供者來管理檔案分享和會話主機。
若要在會話主機加入Microsoft Entra ID時使用Azure 檔案儲存體，您需要將讀取器與資料存取Azure角色基礎存取控制 (RBAC) 角色同時指派給Azure虛擬桌面與Azure虛擬桌面 ARM 提供者服務主體。 此 RBAC 角色指派允許會話主機使用存取金鑰或 Microsoft Entra 存取儲存帳號。
欲了解如何將 Azure RBAC 角色指派給 Azure 虛擬桌面服務主體，請參閱「將 RBAC 角色分配給 Azure 虛擬桌面服務主體」。 未來更新中，你將不需要指派 Azure 虛擬桌面 ARM Provider 服務主體。
欲了解更多關於使用 Azure 檔案儲存體與 Microsoft Entra ID、Active Directory 網域服務或 Microsoft Entra Domain Services 連接的會話主機的資訊，請參閱 Azure 檔案儲存體 SMB 存取的身份驗證選項概述。
警告
將 Azure Virtual Desktop ARM Provider 服務主體指派給儲存帳號，會將 Azure 虛擬桌面服務授予儲存帳號內的所有資料。 我們建議你只將與 App Attach 一起使用的應用程式儲存在這個儲存帳號中，並定期更換存取金鑰。
若要Azure 檔案儲存體 Active Directory 網域服務，你需要將 Storage File Data SMB Share Reader Azure RBAC) 角色導向存取 (控制（RPC）分配為預設的共享層級權限，並設定 NTFS 權限以賦予每個會話主機電腦物件的讀取權限。
欲了解更多關於使用 Azure 檔案儲存體與 Microsoft Entra ID、Active Directory 網域服務或 Microsoft Entra Domain Services 連接的會話主機的資訊，請參閱 Azure 檔案儲存體 SMB 存取的身份驗證選項概述。
對於 Azure NetApp Files，你可以建立一個 SMB 磁碟區，並設定 NTFS 權限，讓每位會話主機的電腦物件都能讀取。 您的會話主機必須加入 Active Directory 網域服務或 Microsoft Entra Domain Services。
你可以用 PsExec 驗證權限是否正確。 欲了解更多資訊，請參閱 檢查檔案分享存取權。
效能
需求會因映像中儲存的多個封裝應用程式而大相逕庭，你需要測試應用程式以了解需求。 對於較大的影像，你需要分配更多頻寬。 下表舉例說明每個會話主機對於一個包含一個應用程式的單一 1 GB 映像檔或 App-V 套件的需求：
| 資源 | 需求 |
|---|---|
| 穩態眼壓眼壓 | 一次內視壓 |
| 機器開機登入 | 10 次 IOP |
| 延遲 | 400毫秒 |
為了優化您的應用程式效能，我們建議：
你的檔案分享應該和你的會話主機在同一個 Azure 區域。 如果你使用 Azure 檔案儲存體，你的儲存帳號必須與會話主機位於同一個 Azure 區域。
排除包含你應用程式的磁碟映像檔，因為它們是唯讀掃描。
確保您的儲存與網路結構能提供足夠的效能。 你應該避免用同一個檔案分享來搭配 FSLogix 設定檔容器。
可用性
任何針對 Azure 虛擬桌面的災難復原計畫，都必須包含將檔案分享複製到你的次要故障轉移位置。 你也需要確保你的檔案分享路徑在次要位置是可存取的。 例如，你可以使用 Distributed File System (DFS) 命名空間，搭配 Azure 檔案儲存體，在不同檔案共享間提供單一的共享名稱。 欲了解更多關於 Azure 虛擬桌面災難復原的資訊，請參閱「建立業務持續性與災難復原計畫」。
Azure 檔案
Azure 檔案儲存體對每個根目錄、目錄和檔案的開啟句柄數量有限制。 VHDX 或 CimFS 磁碟映像檔是透過會話主機的電腦帳號掛載，意即每個磁碟映像檔每個會話主機開啟一個句柄，而非每個使用者。 欲了解更多關於限制與大小調整指引的資訊，請參閱 Azure 檔案儲存體態擴展性與效能目標，以及 Azure 虛擬桌面的 Azure 檔案儲存體型大小指引。
MSIX 與 Appx 套件憑證
所有 MSIX 與 Appx 套件都需要有效的程式碼簽署憑證。 要在 App Attach 使用這些套件，你需要確保整個憑證鏈在你的會話主機上都被信任。 程式碼簽署憑證具有物件識別碼 1.3.6.1.5.5.7.3.3。 你可以從以下管道取得包裹的代碼簽署憑證：
加州) (公共憑證機構。
內部企業或獨立憑證授權中心，例如 Active Directory 憑證服務。 你需要匯出程式碼簽署憑證，包括它的私鑰。
像是 PowerShell 指令檔 New-SelfSignedCertificate 這類工具，可以產生自簽憑證。 你應該只在測試環境中使用自簽憑證。 欲了解更多關於為 MSIX 和 Appx 套件建立自簽憑證的資訊，請參見 「建立套件簽署憑證」。
取得憑證後，你需要用該憑證數位簽署你的 MSIX 或 Appx 套件。 你可以在建立 MSIX 套件時使用 MSIX 包裝工具 來簽署你的套件。 欲了解更多資訊，請參閱「 從任何桌面安裝程式建立 MSIX 套件」。
為了確保憑證在你的會話主機上被信任，你需要你的會話主機信任整個憑證鏈。 你的會話主機如何信任憑證鏈，取決於你從哪裡取得憑證，以及你如何管理會話主機和你使用的身份提供者。 下表提供一些指引，說明如何確保您的會話主機信任該憑證：
公共憑證：來自公共憑證的憑證在 Windows 和 Windows Server 中預設受信任。
內部企業CA：
對於加入 Active Directory 的會話主機，且 AD CS 設定為內部企業 CA，預設會被信任並儲存在 Active Directory 網域服務的設定命名上下文中。 當 AD CS 被設定為獨立 CA 時，你需要設定群組原則，將根憑證和中介憑證分發給會話主機。 欲了解更多資訊，請參閱「使用群組原則分發憑證給 Windows 裝置」。
對於連接 Microsoft Entra ID 的會話主機，你可以使用 Microsoft Intune 將根憑證和中介憑證分發給會話主機。 欲了解更多資訊，請參閱 Microsoft Intune 的受信任根憑證設定檔。
對於使用 Microsoft Entra 混合加入的會話主機，你可以根據需求使用上述任一方法。
自簽：將受信任根安裝到每個會話主機的 受信任根認證機構 儲存。 我們不建議使用群組原則或 Intune 分發此憑證，因為它僅用於測試。
重要事項
你應該為包裹標註時間戳記，讓其有效期能超過證書的有效期限。 否則，憑證過期後，你需要更新套件並換上新的有效憑證，並再次確保會話主機信任憑證鏈。