Azure 虛擬桌面中的應用程式連結和 MSIX 應用程式連結
Azure 虛擬桌面中有兩個功能可讓您將應用程式套件的應用程式動態連結至 Azure 虛擬桌面中的使用者工作階段 - 應用程式連結和 MSIX 應用程式連結。 對於應用程式連結和 MSIX 應用程式連結，應用程式不會安裝在工作階段主機或映像本機上，讓您更輕鬆地為工作階段主機建立自訂映像，並降低組織的營運負荷和成本。 應用程式會在容器內執行，以分隔用戶資料、作業系統和其他應用程式，提高安全性，讓他們更容易進行疑難排解。
下表比較 MSIX 應用程式連結和應用程式連結：
| MSIX 應用程式連結 | 應用程式連結 |
|---|---|
| 應用程式會使用 RemoteApp 或桌面工作階段的一部分來傳遞。 權限是由指派給應用程式群組來控制，不過所有桌面使用者都會在桌面應用程式群組中看到所有 MSIX 應用程式連結應用程式。 | 應用程式會使用 RemoteApp 或桌面工作階段的一部分來傳遞。 存取權限是依據使用者和應用程式套用的，讓您更充分掌控使用者可在遠端工作階段中存取哪些應用程式。 桌面使用者只會看到應用程式指派給他們的應用程式連結。 |
| 應用程式只能在一個主機集區上執行。 如果您想要在另一個主機集區上執行，您必須建立另一個套件。 | 同一個應用程式套件可以跨多個主機集區使用。 |
| 應用程式只能在將其新增的主機集區上執行。 | 應用程式可以在與應用程式套件相同的 Azure 區域中執行 Windows 用戶端作業系統的任何工作階段主機上執行。 |
| 若要更新應用程式，您必須使用另一個套件版本刪除並重新建立應用程式。 您應該在維護期間內更新應用程式。 | 應用程式可以在新的磁碟映像中升級至新的應用程式版本，而不需要維護期間。 |
| 使用者不能在同一部工作階段主機上執行同一應用程式的兩個版本。 | 使用者可以在同一部工作階段主機上同時執行同一應用程式的兩個版本。 |
| 使用量和健康情況的遙測現在可透過 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 的所有功能，以及其他讓 Appx 更適合企業使用的功能。
適用於 Windows 的 Microsoft Application Virtualization （App-V） 會將 Win32 應用程式以虛擬應用程式的形式提供給使用者。 虛擬應用程式會安裝在集中管理的伺服器上，並即時以服務的形式傳送給使用者，並視需要提供。 使用者從熟悉的存取點啟動虛擬應用程式，並與它們互動，就像是在本機安裝一樣。
提示
選取本文頂端的按鈕，在應用程式連結和 MSIX 應用程式連結之間進行選擇，以查看相關文件。
您可以從軟體廠商取得 MSIX 套件，也可以 從現有的安裝程式建立 MSIX 套件。 若要深入瞭解 MSIX，請參閱 什麼是 MSIX？
使用者如何取得應用程式
您可以將不同的應用程式指派給相同主機集區或相同工作階段主機上的不同使用者。 登入期間，必須符合下列三項需求，使用者才能在正確的時間取得正確的應用程式：
應用程式必須指派給主機集區。 將應用程式指派給主機集區可讓您選擇性地選擇應用程式可用的主機集區，以確保應用程式可以使用正確的硬體資源。 例如，如果應用程式需要大量圖形，您可以確定它只會在具有 GPU 最佳化工作階段主機的主機集區上執行。
使用者必須能夠登入主機集區中的工作階段主機，因此他們必須在桌面或 RemoteApp 應用程式群組中。 對於 RemoteApp 應用程式群組，應用程式連結應用程式必須新增至應用程式群組，但您不需要將應用程式新增至桌面應用程式群組。
應用程式必須指派給使用者。 您可以使用群組或使用者帳戶。
如果符合所有需求，使用者就會取得應用程式。 此程序可以控制誰取得哪個主機集區上的應用程式，以及如何讓單一主機集區內的使用者，甚至登入具有多工作階段之相同工作階段主機的使用者，取得不同的應用程式組合。 不符合需求的使用者不會取得應用程式。
使用者如何取得應用程式
您可以將不同的應用程式指派給相同主機集區中的不同使用者。 使用 MSIX 應用程式連結時，您會將 MSIX 套件新增至主機集區，並使用桌面或 RemoteApp 應用程式群組來控制應用程式的指派。 登入期間，必須符合下列需求，使用者才能在正確的時間取得正確的應用程式：
使用者必須能夠登入主機集區中的工作階段主機，因此他們必須在桌面或 RemoteApp 應用程式群組中。
MSIX 映像必須新增至主機集區。
如果符合這些需求，使用者就會取得應用程式。 使用桌面應用程式群組指派應用程式會將應用程式新增至使用者的開始功能表。 不符合需求的使用者不會取得應用程式。
應用程式映像
您必須先使用 MSIXMGR 工具從現有的應用程式套件 建立 MSIX 映像 ，才能將您的應用程式套件使用於 Azure 虛擬桌面。 接著，您必須將每個磁碟映像儲存在工作階段主機可以存取的檔案共用上。 如需檔案共用需求的詳細資訊，請參閱 檔案共用。
：：： zone-pivot=“app-attach” 如果使用 App-V，請參閱 建立和管理 App-V 虛擬化應用程式。 ::: zone-end
磁碟映像類型
針對 MSIX 和 Appx 磁碟映射，您可以使用 複合映射文件系統 （CimFS）、 VHDX 或 VHD，但我們不建議使用 VHD。 掛接和卸載 CimFS 映像的速度比 VHD 和 VHDX 檔案更快，而且耗用較少的 CPU 和記憶體。 只有在工作階段主機執行 Windows 11 時，才建議針對應用程式映像使用 CimFS。
CimFS 映像是數個檔案的組合：一個檔案具有 .cim 副檔名，並包含中繼資料，以及至少兩個其他檔案，一個從 objectid_ 開始，另一個包含實際應用程式資料的則從 region_ 開始。 隨附 .cim 檔案的檔案沒有副檔名。 下表是針對 CimFS 映像找到的範例檔案清單：
| File name | 大小 |
|---|---|
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 之間的效能比較。 這些數字是測試回合的結果，每個格式各有大小為 300 MB 的 500 個檔案，並在 DSv4 Azure 虛擬機器 上執行測試。
| 計量 | VHD | CimFS |
|---|---|---|
| 平均裝載時間 | 356 毫秒 | 255 毫秒 |
| 平均卸載時間 | 1615 毫秒 | 36 毫秒 |
| 記憶體使用量 | 6% (8 GB 中) | 2% (8 GB 中) |
| CPU (計數尖峰) | 已超過多次 | 無效果 |
應用程式註冊
應用程式連結會在登入期間將包含您應用程式的磁碟映像或 App-V 套件掛接至使用者工作階段，然後註冊程式可讓使用者使用應用程式。 註冊類型有兩種：
MSIX 應用程式會在登入期間將包含您應用程式的磁碟映像掛接至使用者的工作階段，然後註冊程序可讓使用者能使用應用程式。 註冊類型有兩種：
隨選：應用程式只會在登入時部分註冊，應用程式的完整註冊會延後，直到使用者啟動應用程式為止。 建議您使用隨選註冊類型，因為它不會影響登入 Azure 虛擬桌面所需的時間。 隨選是預設的註冊方法。
登入封鎖：您指派給使用者的每個應用程式都會完全註冊。 註冊會在使用者登入其工作階段時發生，這可能會影響登入 Azure 虛擬桌面的時間。
重要
所有 MSIX 和 Appx 應用程式套件都包含憑證。 您必須負責確認您的環境信任憑證。 自我簽署憑證支援適當的信任鏈結。
應用程式連結不會限制使用者可以使用的應用程式數目。 您應該考慮可用的網路輸送量，以及每個檔案 (每個映像) 檔案共用支援的開啟控制代碼數目，因為它可能會限制您可以支援的使用者或應用程式數目。 如需詳細資訊，請參閱 檔案共用。
重要
所有 MSIX 應用程式套件都包含憑證。 您必須負責確認您的環境信任憑證。 不支援自我簽署憑證。
MSIX 應用程式連結不會限制使用者可以使用的應用程式數目。 您應該考慮可用的網路輸送量，以及每個檔案 (每個映像) 檔案共用支援的開啟控制代碼數目，因為它可能會限制您可以支援的使用者或應用程式數目。 如需詳細資訊，請參閱 檔案共用。
應用程式狀態
應用程式套件會設定為 作用 中或 非使用中。 將套件設定為作用中可讓使用者能使用應用程式。 Azure 虛擬桌面會忽略設定為非作用中的套件，且當使用者登入時不會新增。
MSIX 套件會設定為 作用中 或 非作用中。 將 MSIX 套件設定為作用中可讓使用者能使用應用程式。 Azure 虛擬桌面會忽略設定為非作用中的 MSIX 套件，而且當使用者登入時不會新增。
新版本的應用程式
您可以提供包含已更新應用程式的新映像，以新增應用程式的新版本。 有兩種方式可以使用使用這個新映像：
並存：使用新的磁碟映像建立新的應用程式，並將它指派給與現有應用程式相同的主機集區和使用者。
就地：建立新的映像，其中應用程式的版本號碼會改變，然後更新現有的應用程式以使用新的映像。 版本號碼可以更高或更低，但您無法使用相同的版本號碼更新應用程式。 在所有使用者停止使用之前，請勿刪除現有的映像。
更新之後，使用者會在下次登入時取得已更新的應用程式版本。 使用者新增新版本時，不需要停止使用舊版本。
新版本的應用程式
使用 MSIX 應用程式連結時，您必須刪除應用程式套件，然後使用新的磁碟映像建立新的應用程式，並將它指派給相同的主機集區。 您無法像應用程式連結一樣就地更新。 使用者會在下次登入時，使用更新的應用程式取得新的映像。 您應該在維護期間執行這些工作。
身分識別提供者
了解您可以搭配應用程式連結使用的識別提供者。
| 識別提供者 | 狀態 |
|---|---|
| Microsoft Entra ID | 支援 |
| Active Directory Domain Services (AD DS) | 支援 |
| Microsoft Entra 網域服務 | 不支援 |
以下是您可以搭配 MSIX 應用程式連結使用的識別提供者：
| 識別提供者 | 狀態 |
|---|---|
| Microsoft Entra ID | 不支援 |
| Active Directory Domain Services (AD DS) | 支援 |
| Microsoft Entra 網域服務 (Azure AD DS) | 不支援 |
檔案共用
應用程式連結要求您的應用程式映像儲存在 SMB 檔案共用上，然後在登入期間掛接在每部工作階段主機上。 應用程式連結與檔案共用所使用的儲存體網狀架構類型沒有相依性。 建議您使用 Azure 檔案儲存體 ，因為它與 Microsoft Entra ID 或 Active Directory Domain Services 相容，並在成本和管理負荷之間提供絕佳的價值。
您也可以使用 Azure NetApp Files，但這需要您的工作階段主機加入 Active Directory Domain Services。
MSIX 應用程式連結要求您的應用程式映像儲存在 SMB 第 3 版檔案共用上，然後在登入期間掛接在每部工作階段主機上。 MSIX 應用程式連結與檔案共用所使用的儲存體網狀架構類型沒有相依性。 建議您使用 Azure 檔案儲存體 ，因為它與您可以用於 MSIX 應用程式連結的支援識別提供者相容，並在成本和管理負荷之間提供絕佳的價值。 您也可以使用 Azure NetApp Files，但這需要您的工作階段主機加入 Active Directory Domain Services。
下列各節提供檔案共用需要的存取權限、效能和可用性的一些指引。
權限
每一部工作階段主機都會從檔案共用掛接應用程式映像。 您必須設定 NTFS 和共用存取權限，以允許每部工作階段主機電腦物件讀取檔案和檔案共用的存取權限。 設定正確使用權限的方式取決於您用於檔案共用和工作階段主機的儲存體提供者和身分識別提供者。
若要在工作階段主機加入 Microsoft Entra ID 時使用 Azure 檔案儲存體，您必須將 Reader and Data Access 這個 Azure 角色型存取控制 (RBAC) 角色指派給 Azure 虛擬桌面 和 Azure 虛擬桌面 ARM 提供者 服務主體。 此 RBAC 角色指派可讓您的工作階段主機使用存取密鑰或Microsoft Entra 來存取記憶體帳戶。
若要瞭解如何將 Azure RBAC 角色指派給 Azure 虛擬桌面服務主體，請參閱 將 RBAC 角色指派給 Azure 虛擬桌面服務主體。 在未來的更新中，您不需要指派 Azure 虛擬桌面 ARM 提供者 服務主體。
如需將 Azure 檔案儲存體使用於已加入 Microsoft Entra ID、Active Directory Domain Services 或 Microsoft Entra Domain Services 的工作階段主機的詳細資訊，請參閱 用於 SMB 存取的 Azure 檔案儲存體身分識別型驗證選項概觀。
警告
將 Azure 虛擬桌面 ARM 提供者 服務主體指派給儲存體帳戶，會將 Azure 虛擬桌面服務授予儲存體帳戶內的所有資料。 建議您只將要搭配應用程式連結使用的應用程式儲存在此儲存體帳戶中，並定期輪替存取密鑰。
對於具有 Active Directory Domain Services 的 Azure 檔案儲存體，您必須將 Storage File Data SMB Share Reader 這個 Azure 角色型存取控制 (RBAC) 角色指派為 預設共用層級存取權限，並 設定 NTFS 存取權限 ，以授予對每部工作階段主機的電腦物件的讀取權限。
如需將 Azure 檔案儲存體使用於已加入 Microsoft Entra ID、Active Directory Domain Services 或 Microsoft Entra Domain Services 的工作階段主機的詳細資訊，請參閱 用於 SMB 存取的 Azure 檔案儲存體身分識別型驗證選項概觀。
對於具有 Active Directory Domain Services 的 Azure 檔案儲存體，您必須將 Storage File Data SMB Share Reader 這個 Azure 角色型存取控制 (RBAC) 角色指派為 預設共用層級存取權限，並 設定 NTFS 存取權限 ，以授予對每部工作階段主機的電腦物件的讀取權限。
如需將 Azure 檔案儲存體使用於已加入 Active Directory Domain Services 或 Microsoft Entra Domain Services 的工作階段主機的詳細資訊，請參閱 用於 SMB 存取的 Azure 檔案儲存體身分識別型驗證選項概觀。
- 對於 Azure NetApp Files，您可以 建立 SMB 磁碟區 並設定 NTFS 存取權限，以授予對每部工作階段主機的電腦物件的讀取權限。 您的工作階段主機必須加入 Active Directory Domain Services 或 Microsoft Entra 網域服務。
您可以使用 PsExec 來驗證權限是否正確。 如需詳細資訊，請參閱 檢查檔案共用存取。
效能
需求可能會因映像中儲存了多少個已封裝的應用程式而有所不同，而您需要測試應用程式以瞭解您的需求。 對於較大的映像，您需要配置更多頻寬。 下表提供單一 1 GB 映射或 App-V 套件的需求範例，其中包含每個會話主機需要一個應用程式：
| 資源 | 需求 |
|---|---|
| 穩定狀態 IOPS | 一個 IOP |
| 電腦開機登入 | 10 IOPS |
| Latency | 400 毫秒 |
若要將應用程式的效能最佳化，建議您：
您的檔案共用應位於與工作階段主機相同的 Azure 區域中。 如果您使用 Azure 檔案儲存體，儲存體帳戶必須位於與工作階段主機相同的 Azure 區域中。
將包含應用程式的磁碟映像從防病毒軟體掃描中排除，因為它們是唯讀的。
請確認您的儲存體和網路網狀架構可以提供足夠的效能。 您應該避免使用與 FSLogix 設定檔案容器 相同的檔案共用。
可用性
Azure 虛擬桌面的任何災害復原方案都必須包含將檔案共用復寫至次要故障轉移位置。 您也必須確認您的檔案共用路徑可在次要位置存取。 例如，您可以將 分散式檔案系統 (DFS) 命名空間與 Azure 檔案儲存體 搭配使用，在不同的檔案共享之間提供單一共用名稱。 若要深入瞭解 Azure 虛擬桌面的災害復原，請參閱 建立商務持續性和災害復原計劃。
Azure 檔案
Azure 檔案儲存體對每個根目錄、目錄和檔案的開啟控制代碼數目有所限制。 使用應用程式連結或 MSIX 應用程式連結時，VHDX 或 CimFS 磁碟映像會使用工作階段主機的電腦帳戶掛接，這表示每個磁碟映像都會為每部工作階段主機開啟一個控制代碼，而不是每個使用者。 如需限制和調整大小指引的詳細資訊，請參閱 Azure 檔案儲存體可擴縮性和效能目標 和 Azure 虛擬桌面的 Azure 檔案調整大小指引。
MSIX 和 Appx 套件憑證
所有 MSIX 和 Appx 套件都需要有效的程式碼簽署憑證。 若要搭配應用程式連結使用這些套件，您必須確認工作階段主機信任整個憑證鏈結。 程式碼簽署憑證具有物件識別碼 1.3.6.1.5.5.7.3.3。 您可以從以下來源取得套件的程式碼簽署憑證：
公開憑證授權單位 (CA)。
內部企業或獨立憑證授權單位，例如 Active Directory 憑證服務。 您必須匯出程式碼簽署憑證，包括其私密金鑰。
類似 PowerShell Cmdlet New-SelfSignedCertificate 能產生自我簽署憑證的工具。 您應該只在測試環境中使用自我簽署憑證。 如需為 MSIX 和 Appx 套件建立自我簽署憑證的詳細資訊，請參閱 建立套件簽署憑證。
取得憑證之後，您必須使用憑證以數位方式簽署 MSIX 或 Appx 套件。 您可以在建立 MSIX 套件時，使用 MSIX 封裝工具 簽署套件。 如需詳細資訊，請參閱 從任何桌面安裝程式建立 MSIX 套件。
若要確保您的工作階段主機上信任憑證，您需要讓工作階段主機信任整個憑證鏈結。 執行此動作的方式取決於您從何處取得憑證，以及如何管理工作階段主機和您使用的識別提供者。 下表提供如何確認工作階段主機信任憑證的一些指引：
公開 CA：Windows 和 Windows Server 預設會信任來自公開 CA 的憑證。
內部企業 CA：
對於已加入 Active Directory 的工作階段主機，AD CS 設定為內部企業 CA，預設會受到信任，並儲存在 Active Directory Domain Services 的組態命名內容中。 當 AD CS 設定為獨立 CA 時，您必須設定群組原則，將根憑證和中繼憑證散發給工作階段主機。 如需詳細資訊，請參閱 使用群組原則將憑證散發至 Windows 裝置。
對於已加入 Microsoft Entra ID 的工作階段主機，您可以使用 Microsoft Intune 將根憑證和中繼憑證散發給工作階段主機。 如需詳細資訊，請參閱 Microsoft Intune 信任的根憑證設定檔。
對於使用 Microsoft Entra 混合式聯結的工作階段主機，您可以視需求使用上述任一方法。
自我簽署：在每部工作階段主機上，將受信任的根憑證安裝到 信任的根憑證授權單位 存放區。 不建議使用群組原則或 Intune 散發此憑證，因為它只應該用於測試。
重要
您應該為套件加上時間戳記，使其有效期限超過憑證到期日。 否則，一旦憑證過期，您必須使用新的有效憑證來更新套件，並再次確保您的工作階段主機信任它。