應用程式連結可讓您將應用程式從應用程式套件動態連結至 Azure 虛擬桌面中的使用者工作階段。 應用程式不會在本機安裝在工作階段主機或映像上，因此可以更輕鬆地為工作階段主機建立自訂映像，並降低組織的營運額外負荷和成本。 應用程式在容器內運行，將使用者資料、作業系統和其他應用程式分開，從而提高安全性並使其更易於故障排除。
以下是 App Attach 的一些主要優點：
- 應用程式會使用 RemoteApp 或作為桌面工作階段的一部分傳遞。 權限會針對每個使用者的應用程式套用，讓您更好地控制使用者可以在遠端工作階段中存取哪些應用程式。 桌面使用者只會看到指派給他們的應用程式附加應用程式。
- 相同的應用程式套件可以跨多個主機集區使用。
- 應用程式可以在與應用程式套件相同的 Azure 區域中執行 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 適用於 Windows 的 App-V) (應用程式虛擬化，將 Win32 應用程式作為虛擬應用程式提供給使用者。 虛擬應用程式安裝在集中管理的伺服器上，並根據需要即時以服務形式交付給使用者。 使用者從熟悉的存取點啟動虛擬應用程式並與它們互動，就像它們安裝在本機一樣。
您可以從軟體廠商取得 MSIX 套件，也可以 從現有的安裝程式建立 MSIX 套件。 若要深入瞭解 MSIX，請參閱 什麼是 MSIX？。
使用者如何取得應用程式
您可以將不同的應用程式指派給相同主機集區或相同工作階段主機上的不同使用者。 在登入期間，使用者必須符合下列所有三個需求，才能在正確的時間取得正確的應用程式：
應用程式必須指派給主機集區。 將應用程式指派給主機集區可讓您選擇應用程式可用的主機集區，以確保應用程式可以使用正確的硬體資源。 例如，如果應用程式是圖形密集型，您可以確保它只在具有 GPU 最佳化工作階段主機的主機集區上執行。
使用者必須能夠登入主機集區中的工作階段主機，因此他們必須位於桌面或 RemoteApp 應用程式群組中。 對於 RemoteApp 應用程式群組，必須將應用程式附加應用程式新增至應用程式群組，但您不需要將應用程式新增至桌面應用程式群組。
必須將應用程式指派給使用者。 您可以使用群組或使用者帳戶。
如果滿足所有這些要求，用戶就會獲得應用程序。 此程式可讓您控制誰在哪個主機集區取得應用程式，以及單一主機集區內的使用者，甚至登入相同的多會話會話主機，以取得不同的應用程式組合。 不符合要求的使用者不會取得應用程式。
應用圖片
您必須先從現有的應用程式套件建立 MSIX 映像 ，才能搭配 Azure 虛擬桌面使用 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-V 套件從檔案共用掛接到使用者的工作階段，然後註冊程式會讓應用程式可供使用者使用。 註冊有兩種類型：
隨選：應用程式只會在登入時部分註冊，而應用程式的完整註冊會延遲到使用者啟動應用程式為止。 隨選是建議您使用的註冊類型，因為它不會影響登入 Azure 虛擬桌面所需的時間。 隨選是預設註冊方法。
登入封鎖：您指派給使用者的每個應用程式都已完全註冊。 註冊會在使用者登入其會話時發生，這可能會影響登入 Azure 虛擬桌面的時間。
重要事項
所有 MSIX 和 Appx 應用程式套件都包含憑證。 您有責任確保憑證在您的環境中受到信任。 適當的信任鏈支援自我簽署憑證。
App Attach 不會限制使用者可以使用的應用程式數量。 您應該考慮可用的網路輸送量，以及檔案共用支援的每個映像 (每個檔案) 開啟控制碼數目，因為它可能會限制您可以支援的使用者或應用程式數目。 如需詳細資訊，請參閱 檔案共用。
應用程式狀態
應用程式套件會設定為 作用中 或 非作用中。 設定為作用中的套件會讓使用者可以使用應用程式。 Azure 虛擬桌面會忽略設定為 非作用中的 套件，而且不會在使用者登入時新增。
新版本的應用程式
您可以提供包含已更新應用程式的新映像檔，以新增應用程式的新版本。 您可以透過兩種方式使用此新映像：
並排：使用新的磁碟映像建立新的應用程式，並將其指派給與現有應用程式相同的主機集區和使用者。
就地：建立應用程式版本號碼變更的新映像，然後更新現有的應用程式以使用新映像。 版本號碼可以更高或更低，但您無法更新具有相同版本號碼的應用程式。 在所有使用者都使用完現有影像之前，請勿刪除現有影像。
更新後，使用者會在下次登入時取得更新的應用程式版本。 使用者不需要停止使用舊版來新增版本。
身分識別提供者
以下是您可以與 App Attach 搭配使用的身分識別提供者：
| 身分識別提供者 | 狀態 |
|---|---|
| Microsoft Entra ID | 支援 |
| Active Directory Domain Services (AD DS) | 支援 |
| Microsoft Entra Domain Services | 不支援 |
檔案共用
應用程式連結要求您的應用程式映像儲存在 SMB 檔案共用上，然後在登入期間掛接在每個工作階段主機上。 應用程式連結與檔案共用所使用的儲存體網狀架構類型沒有相依性。 建議您使用 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 提供者 服務主體。
如需將 Azure 檔案儲存體與加入 Microsoft Entra ID、Active Directory 網域服務或 Microsoft Entra Domain Services 的工作階段主機搭配使用的詳細資訊，請參閱 Azure 檔案儲存體概觀SMB 存取的身分識別型驗證選項。
警告
將 Azure 虛擬桌面 ARM 提供者 服務主體指派給儲存體帳戶，會將 Azure 虛擬桌面服務授與儲存體帳戶內的所有資料。 建議您只在此儲存體帳戶中儲存要與應用程式連結搭配使用的應用程式，並定期輪替存取金鑰。
針對具有Active Directory 網域服務的Azure 檔案儲存體，您必須將儲存體檔案資料 SMB 共用讀取器 Azure 角色型存取控制 (RBAC) 角色指派為預設共用層級許可權，並設定 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 套件每個會話主機所需的需求範例：
| 資源 | 需求 |
|---|---|
| 穩態 IOP | 一個眼壓 |
| 電腦開機登入 | 10 IOP |
| 延遲 | 400 毫秒 |
為了優化應用程式的效能，我們建議：
您的檔案共用應該與工作階段主機位於相同的 Azure 區域中。 如果您使用 Azure 檔案儲存體，您的儲存體帳戶必須與工作階段主機位於相同的 Azure 區域中。
從防毒掃描中排除包含應用程式的磁碟映像，因為它們是唯讀的。
確保您的儲存體和網路網狀架構能夠提供足夠的效能。 您應該避免將相同的檔案共用與 FSLogix 設定檔容器搭配使用。
可用性
Azure 虛擬桌面的任何災害復原計劃都必須包含將檔案共用複寫至次要容錯移轉位置。 您還需要確保您的文件共享路徑可以在次要位置訪問。 例如，您可以使用分散式檔案系統 (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。 您可以從下列位置取得套件的程式碼簽署憑證：
公用憑證授權單位 (CA) 。
內部企業或獨立憑證授權單位，例如 Active Directory 憑證服務。 您需要匯出程式碼簽署憑證，包括其私密金鑰。
產生自我簽署憑證的工具，例如 PowerShell Cmdlet New-SelfSignedCertificate 。 您應該只在測試環境中使用自我簽署憑證。 如需建立 MSIX 和 Appx 套件自我簽署憑證的詳細資訊，請參閱 建立套件簽署的憑證。
取得憑證之後，您必須使用憑證以數位方式簽署 MSIX 或 Appx 套件。 當您建立 MSIX 套件時，您可以使用 MSIX 封裝工具 來簽署套件。 如需詳細資訊，請參閱 從任何桌面安裝程式建立 MSIX 套件。
若要確保憑證在階段作業主機上受信任，您需要階段作業主機信任整個憑證鏈結。 工作階段主機信任憑證鏈的方式取決於您從何處取得憑證，以及您如何管理工作階段主機和您使用的身分識別提供者。 下表提供一些指引，說明如何確保憑證在工作階段主機上受信任：
公用 CA：公用 CA 的憑證預設會在 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 散發此憑證，因為它應該只用於測試。
重要事項
您應該為套件加上時間戳記，使其有效性可以超過憑證的到期日。 否則，一旦憑證到期，您必須使用新的有效憑證來更新套件，並再次確保會話主機信任憑證鏈。
後續步驟
瞭解如何在 Azure 虛擬桌面中新增和管理應用程式附加應用程式。