Azure 虛擬桌面中的應用程式附加

應用程式附加可讓您從應用程式套件動態附加至 Azure 虛擬桌面中的使用者工作階段。 應用程式不會安裝在本機工作階段主機或映像上，因此可以更輕鬆地為工作階段主機建立自訂映像，並減少組織的營運額外負荷和成本。 應用程式會在容器內執行，容器會分離使用者資料、作業系統和其他應用程式，從而提高安全性並使其更容易進行疑難排解。

以下是應用程式附加的一些主要優點：

• 應用程式是使用 RemoteApp 或作為桌面工作階段的一部分提供。 每個使用者都會套用每個應用程式的權限，讓您能夠更好地控制使用者在遠端工作階段中可以存取的應用程式。 桌面使用者只會看到指派給他們的應用程式附加應用程式。

• 相同的應用程式套件可以跨多個主機集區使用。

• 應用程式可以在與應用程式套件相同的 Azure 區域中執行 Windows 用戶端或支援的 Windows 伺服器作業系統的任何工作階段主機上執行。

• 應用程式可以使用新的磁碟映像升級至新的應用程式版本，而不需要維護時段。

• 使用者可以在相同的工作階段主機上同時執行相同應用程式的多個版本。

• 使用情況與健康情況遙測可透過 Azure Log Analytics 取得。

您可以使用下列應用程式套件類型和檔案格式：

MSIX 和 Appx 是 Windows 應用程式套件格式，可提供新式封裝體驗給 Windows 應用程式。 應用程式會在容器內執行，容器會分離使用者資料、作業系統和其他應用程式，從而提高安全性並使其更容易進行疑難排解。 MSIX 和 Appx 很相似，主要差異在於 MSIX 是 Appx 的超集。 MSIX 支援 Appx 的所有功能，以及其他使其更適合企業使用的功能。

Microsoft Application Virtualization (適用於 Windows 的 App-V) 以虛擬應用程式的方式向使用者提供 Win32 應用程式。 虛擬應用程式安裝在集中管理的伺服器上，並根據需要以服務的形式即時交付給使用者。 使用者從熟悉的存取點啟動虛擬應用程式，並與它們互動，就像它們安裝在本機一樣。

您可以從軟體廠商取得 MSIX 套件，也可以 從現有的安裝程式建立 MSIX 套件。 若要深入了解 MSIX，請參閱什麼是 MSIX？。

使用者如何取得應用程式

您可以將不同的應用程式指派給相同主機集區或相同階段作業主機上的不同使用者。 登入時，使用者必須符合下列三個需求，才能在正確的時間取得正確的應用程式：

• 必須將應用程式指派給主機集區。 將應用程式指派給主機集區可讓您選擇應用程式可用的主機集區，以確保應用程式可以使用正確的硬體資源。 例如，如果應用程式是圖形密集型的，您可以確保它只在具有 GPU 最佳化工作階段主機的主機集區上執行。

• 使用者必須能夠登入主機集區中的工作階段主機，所以他們必須位於Desktop 或 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 映像範例檔案清單：

下表是 VHDX 和 CimFS 之間的效能比較。 這些數字是對每種格式的 500 個文件（每個 300 MB）進行測試運行的結果，並且測試是在 DSv4 Azure 虛擬機器上執行的。

申請註冊

應用程式附加會在登入期間，將包含您應用程式的磁碟映像或 App-V 套件從檔案共用掛接到使用者的工作階段，然後註冊程序可讓使用者使用應用程式。 註冊有兩種類型：

• 隨選：應用程式僅在登入時部分註冊，而應用程式的完整註冊會延後到使用者啟動應用程式為止。 隨選是我們建議您使用的註冊類型，因為它不會影響登入 Azure 虛擬桌面所需的時間。 隨選是預設註冊方法。

• 登入封鎖：您指派給使用者的每個應用程式都已完全註冊。 註冊會在使用者登入其工作階段時進行，這可能會影響登入 Azure 虛擬桌面的時間。

應用程式附加不會限制使用者可以使用的應用程式數量。 應考慮您的可用網路輸送量，以及每個檔案的開啟控制碼數目 (每個映像) 您的檔案共用支援，因為這可能會限制您可以支援的使用者或應用程式數目。 如需詳細資訊，請參閱 檔案共用。

應用程式狀態

應用程式套件設定為 使用中 或 非使用中。 設定為 [作用中] 的套件會讓使用者使用應用程式。 Azure 虛擬桌面會忽略設定為非使用中且不會在使用者登入時新增的套件。

新版本的應用程式

您可以提供包含已更新應用程式的新映像，以新增應用程式版本。 您可以透過兩種方式使用此新影像：

• 並排：使用新的磁碟映像檔建立新的應用程式，並將其指派給與現有應用程式相同的主機集區和使用者。

• 就地：在應用程式版本號碼變更的新映像中建立新映像，然後更新現有的應用程式以使用新映像。 版本號碼可以更高或更低，但您無法更新具有相同版本號碼的應用程式。 在所有使用者都使用完現有映像之前，請勿刪除它。

更新之後，使用者會在下次登入時取得更新的應用程式版本。 使用者不需要停止使用舊版就能新增新版本。

識別提供者

以下是您可以與 App 附加搭配使用的身分識別提供者：

檔案共用

應用程式附加要求將您的應用程式映像儲存在 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 提供者服務主體。

  如需搭配已加入 Microsoft Entra ID、Active Directory 網域服務或 Microsoft Entra Domain Services 之工作階段主機使用 Azure 檔案儲存體 的詳細資訊，請參閱 Azure 檔案儲存體概觀適用於 SMB 存取的身分識別驗證選項。

  警告

  將 Azure 虛擬桌面 ARM 提供者服務主體指派給儲存體帳戶，會將 Azure 虛擬桌面服務授與儲存體帳戶內的所有資料。 建議您只在此儲存體帳戶中儲存要與 App Attach 搭配使用的應用程式，並定期輪換存取金鑰。

• 對於使用 Active Directory 網域服務 的Azure 檔案儲存體，您需要將儲存檔資料 SMB 共用讀取器Azure角色型存取控制 (RBAC) 角色指派為預設共用層級權限，並設定 NTFS 權限以授與對每個工作階段主機電腦物件的讀取存取權。

  如需搭配已加入 Microsoft Entra ID、Active Directory 網域服務或 Microsoft Entra Domain Services 之工作階段主機使用 Azure 檔案儲存體 的詳細資訊，請參閱 Azure 檔案儲存體概觀適用於 SMB 存取的身分識別驗證選項。

• 針對 Azure NetApp Files，您可以建立 SMB 磁碟區並設定 NTFS 權限，以授與每個工作階段主機電腦物件的讀取存取權。 您的工作階段主機必須加入 Active Directory 網域服務或 Microsoft Entra Domain Services。

您可以使用 PsExec 來驗證權限正確無誤。 如需詳細資訊，請參閱 檢查檔案共用存取權。

使用者和部署組態 Files

針對 透過應用程式附加提供的 App-V 套件，您可以使用 App-V 動態設定檔 來自訂應用程式行為。 App 附加會自動偵測遵循預期命名慣例的標準設定檔。 如果它們與應用程式附加套件位於相同的資料夾中，且 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 安全性群組。 應用程式套件的 [發行者] 欄位值必須設定為目標安全性群組的 [物件識別碼 ]。

登入期間，App Attach 會評估使用者的群組成員資格，並根據相關聯的群組套用適當的使用者設定。

只有當不同的使用者群體需要不同的應用程式設定時，管理員才應該使用多個使用者設定檔;標準部署可以繼續依賴自動偵測到的單一使用者設定檔。

效能

需求可能會因映像中儲存的封裝應用程式數量而有很大差異，您需要測試應用程式以瞭解您的需求。 對於較大的影像，您需要配置更多頻寬。 下表說明單一 1 GB 映像或包含一個應用程式的 App-V 套件，其每個工作階段主機所需的需求範例：

若要最佳化應用程式的效能，建議您：

• 您的檔案共用應與工作階段主機位於相同的 Azure 區域中。 如果您使用的是 Azure 檔案儲存體，您的儲存體帳戶必須與工作階段主機位於相同的 Azure 區域中。

• 將包含您應用程式的磁碟映像排除在防毒掃描之外，因為它們是唯讀的。

• 請確定您的儲存體與網路架構能夠提供足夠的效能。 您應該避免與 FSLogix 設定檔容器使用相同的檔案共用。

可用性

Azure 虛擬桌面的任何災害復原方案都必須包含將檔案共用複寫到次要容錯移轉位置。 您還需要確保您的文件共享路徑在輔助位置中可訪問。 例如，您可以使用分散式檔案系統 (DFS) 命名空間搭配Azure 檔案儲存體，為不同的檔案共用提供單一共用名稱。 若要深入瞭解 Azure 虛擬桌面的災害復原，請參閱設定商務持續性和災害復原方案。

Azure 檔案

Azure 檔案儲存體對每個根目錄、目錄和檔案的開啟控制碼數目有限制。 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 網域服務設定命名內容中。 當 AD CS 設定為獨立 CA 時，您需要設定群組原則，以將根憑證和中繼憑證散發到工作階段主機。 如需詳細資訊，請參閱 使用群組原則將憑證散發到 Windows 裝置。

  • 對於已加入 Microsoft Entra ID 的工作階段主機，您可以使用 Microsoft Intune 將根憑證和中繼憑證散發至工作階段主機。 如需詳細資訊，請參閱 Microsoft Intune 的受信任根憑證設定檔。

  • 對於使用 Microsoft Entra 混合式聯結的工作階段主機，您可以視需求使用上述方法之一。

• 自我簽署： 在每個工作階段主機上，將受 信任的根目錄安裝到受信任的根憑證授權單位 存放區。 我們不建議使用群組原則或 Intune 散發此憑證，因為它應該僅用於測試。

後續步驟

瞭解如何在 Azure 虛擬桌面中新增和管理應用程式附加應用程式。