FSLogix 僅雲端與外部身分識別：Azure Virtual Desktop 設定指南

如果您一直在等待淘汰那些僅為了讓 Azure Virtual Desktop 使用者載入 FSLogix 設定檔而存在的網域控制站，那麼障礙已經消除。自 2026 年 5 月起，僅雲端與外部身分識別的 FSLogix 設定檔容器已正式推出（GA），整個技術堆疊可以完全由已加入 Microsoft Entra 的工作階段主機、以 Microsoft Entra Kerberos 驗證的 Azure Files，以及從未擁有 Active Directory 帳戶的使用者所組成。GA 公告發布時我寫過它代表什麼；本指南則是我現在交給想要實際建置它的團隊的逐步說明，包括那些容易讓人跌倒的部分：應用程式資訊清單標籤、無法使用 icacls 時的目錄權限模型，以及條件式存取排除項目。以下每一個設定路徑與值均來自 2026 年 10 月的 Microsoft Learn。

AVD 工作階段主機的身分識別模型

Azure Virtual Desktop 加入工作階段主機有四種實務上的方式，而身分識別模型決定了 FSLogix 可以向什麼進行驗證。Microsoft 的身分識別與驗證文章明確指出，僅存在於 AD DS 中的使用者完全不受支援；每位 AVD 使用者都必須能透過 Microsoft Entra ID 被探索到。

過去的問題出在第四列。已加入 Entra 的主機多年來一直受支援，但 FSLogix 需要 Kerberos 票證才能掛接 SMB 共用，而只有 AD DS 或 Entra Domain Services 能夠發行。Entra Kerberos 首先為混合式身分識別填補了這個缺口，因為 Entra ID 可以代表已同步的內部部署帳戶發行票證。僅雲端帳戶背後沒有內部部署帳戶可依靠，因此只能得到本機或暫存設定檔。

僅雲端 FSLogix 的意義

Microsoft Entra Kerberos 將租用戶變成 Kerberos 金鑰發佈中心（KDC）。當使用者登入已加入 Entra 的裝置時，Entra ID 會發行主要重新整理權杖（PRT），並同時發行領域為 KERBEROS.MICROSOFTONLINE.COM 的雲端票證授與票證（Cloud TGT）。對於存取 Azure Files 的僅雲端使用者，Entra Kerberos 概觀描述了流程：SMB 用戶端為 cifs/<storageaccount>.file.core.windows.net 要求服務票證，Entra Kerberos 根據 Cloud TGT 發行包含使用者身分識別與群組宣告的票證，再由 Azure Files 驗證。整個過程不涉及任何內部部署 KDC。

時間線對支援對話很重要：

• 2025 年 9 月：AVD 對外部身分識別的支援進入預覽，並明確不支援 FSLogix。
• 2025 年 11 月：外部身分識別正式推出，僅雲端與外部身分識別的 FSLogix 進入預覽。
• 2026 年 5 月：僅雲端與外部身分識別的 FSLogix 支援正式推出。AVD 新功能條目指出，此功能「已內建於現有版本的 FSLogix 中」。

最後一句回答了我最常被問到的問題。並不存在某個引進僅雲端支援的 FSLogix 版本號碼；真正的支撐工作發生在 Entra Kerberos、Azure Files 和 Windows 中。Microsoft 的版本資訊確實要求執行最新版本，而目前的版本 FSLogix 26.08（3.26.826.17182，2026 年 8 月 31 日發行）特別值得安裝，因為它有一項功能：在工作階段期間以及 VHD 重新附加時，在背景重新整理使用者的雲端 Kerberos 票證。Microsoft 指出這並不改變 10 小時的票證存留期，但它緩解了過去長時間工作階段後必須登出才能解決的儲存體存取失敗。

外部身分識別支援涵蓋的範圍及其限制

外部身分識別是您邀請到員工租用戶中的 B2B 使用者。就 FSLogix 而言，Azure Files Entra Kerberos 文章劃定了界線：Azure Files SMB 對外部身分識別的支援僅限於 Azure Virtual Desktop 上的 FSLogix 情境，適用於受邀加入公用雲端租用戶的使用者，不包含跨雲端使用者（從 Azure Government 或 21Vianet 受邀者），且在政府雲端中不受支援。Entra Kerberos 也不支援跨租用戶存取；進行驗證的是您租用戶中的來賓物件。外部身分識別無法在工作階段中使用 Kerberos 或 NTLM 向內部部署資源進行驗證，而指派給來賓的 Intune 裝置設定原則也不會套用；您需要改為將這些原則指派給裝置。

必要條件

表中有兩個細節經常讓人踩到地雷。僅雲端支援僅限公用雲端；混合式做法可在 Azure Government 和 21Vianet 中使用，但僅雲端做法不行。此外，外部身分識別的作業系統門檻與僅雲端的門檻並不相同：如果來賓會共用該主機集區，請在挑選映像之前核對兩份清單。

步驟 1：儲存體帳戶與檔案共用

建立儲存體帳戶和用於設定檔的 SMB 檔案共用。FSLogix 操作說明中有一條規則不可妥協：儲存體帳戶不能同時以 Entra ID 和第二種方法（例如 AD DS 或 Entra Domain Services）進行驗證。如果要重複使用曾加入 AD DS 的帳戶，請先變更身分識別來源，並檢視現有的 ACL，因為它們是針對內部部署 SID 撰寫的。

請將設定檔共用放在獨立的儲存體帳戶上。步驟 2 中的條件式存取排除項目適用於代表整個帳戶的應用程式，您不會希望一般用途的資料搭上這項豁免的便車。

步驟 2：在儲存體帳戶上啟用 Microsoft Entra Kerberos

在 Azure 入口網站中開啟儲存體帳戶，然後依序選取 Data storage > Classic file shares，選取 Identity-based access 旁的狀態，在 Microsoft Entra Kerberos 下選取 Set up，勾選 Microsoft Entra Kerberos 核取方塊並選取 Save。略過網域名稱與 GUID 欄位；它們是為想用檔案總管編輯 ACL 的混合式身分識別而設，而這對僅雲端身分識別本來就不受支援。

Set-AzStorageAccount -ResourceGroupName <resourceGroupName> -StorageAccountName <storageAccountName> -EnableAzureActiveDirectoryKerberosForFile $true

az storage account update --name <storageaccountname> --resource-group <resourcegroupname> --enable-files-aadkerb true

啟用此功能會自動建立名為 [Storage Account] .file.core.windows.net 的應用程式註冊。必須對該應用程式執行三件事，漏掉任何一件都會導致設定檔靜默地退回本機。

授與管理員同意。在 Microsoft Entra ID > App registrations > All Applications 中開啟儲存體應用程式，選取 API permissions，然後為三個要求的權限（openid、profile 和 User.Read）選取 Grant admin consent for [Directory Name]。不要變更此服務主體上的任何其他內容；Microsoft 表示超出文件範圍的編輯可能會破壞它。

加入雲端群組標籤。Kerberos 票證最多承載 1,010 個群組 SID，而有了僅雲端支援後，票證必須包含雲端群組 SID。Microsoft 將此步驟標示為僅雲端身分識別必須：開啟應用程式的 Manifest，找到 tags 陣列並加入 "kdc_enable_cloud_group_sids"，然後儲存。或者透過 Graph PowerShell：

Connect-MgGraph -Scopes "Application.ReadWrite.All" -TenantId <tenantId>
Update-MgApplication -ApplicationId "<AppObjectId>" -Tags @("kdc_enable_cloud_group_sids")

有效成員資格仍超過 1,010 個 SID 的使用者會在服務票證階段失敗，登入記錄顯示錯誤 140011 KerberosUsersGroupNumberExceeded；解決方法是減少這些帳戶的巢狀與動態群組成員資格。

將應用程式從 MFA 中排除。Entra Kerberos 沒有使用者介面可在設定檔載入期間完成提升驗證提示。每一條要求 MFA 且以所有資源為目標的條件式存取原則都必須排除儲存體應用程式。如果遺漏此項，掛接共用時會傳回「System error 1327: Account restrictions are preventing this user from signing in.」。另外也要檢查應用程式管理原則：封鎖新增對稱金鑰或將金鑰存留期限制在 366 天以下的原則，需要為 Storage Resource Provider 服務（應用程式識別碼 a6aa9161-5291-40bb-8c5c-923b567bee3b）設定例外，否則啟用 Entra Kerberos 會因 Graph 傳回 BadRequest 而失敗。

如果透過私人端點存取共用，請將 <storageaccount>.privatelink.file.core.windows.net 項目加入應用程式的 identifierUris，否則用戶端會退回 NTLM 並以錯誤 1326 失敗。

步驟 3：共用層級 RBAC

共用層級存取就是 Azure RBAC，而對於僅雲端身分識別，Microsoft 的文件指出，只有在使用 Entra Kerberos 時才支援指派特定的 RBAC 角色，且在所有公用區域可用。相關的內建角色包括：

FSLogix 儲存體權限指引建議將預設共用層級權限設為對所有已驗證身分識別的 Storage File Data SMB Share Contributor，並授與管理員群組 Storage File Data SMB Share Elevated Contributor 以便管理 ACL。在入口網站中的路徑是 Classic file shares > Identity-based access > Step 2: Set share-level permissions > Enable permissions for all authenticated users and groups。如果您偏好明確指派，請將角色範圍限定在共用：

$scope = "/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>/fileServices/default/fileshares/<share-name>"
New-AzRoleAssignment -SignInName <user-principal-name> -RoleDefinitionName "Storage File Data SMB Share Contributor" -Scope $scope

角色指派通常在 30 分鐘內生效。當預設權限與明確指派同時適用時，以較高的權限為準。

步驟 4：不依賴 NTFS 工具的目錄權限

這是僅雲端做法與 AVD 管理員熟知做法差異最大的地方。目錄與檔案層級權限文章提供了一張工具矩陣，對於使用僅雲端身分識別的 Microsoft Entra Kerberos，Windows 檔案總管與 icacls 都被標示為不受支援。您的兩個選項是 Azure 入口網站和 RestSetAcls PowerShell 模組，兩者都不需要網域控制站。

在入口網站中，開啟檔案共用，選取 Browse，然後使用頂端功能表中的 Manage access 設定根 ACL，或在某個目錄上按一下滑鼠右鍵並選擇 Manage access。FSLogix 操作說明將此索引標籤稱為僅雲端與外部身分識別使用者的建議選項。拒絕永遠優先於允許，而可繼承的變更僅適用於未來的項目，因此請在第一位使用者登入之前設定好根 ACL。

使用 PowerShell 時，文件中的模式如下：

Install-Module RestSetAcls
$context = New-AzStorageContext -StorageAccountName "<storage-account-name>" -StorageAccountKey "<storage-account-key>"
Add-AzFileAce -Context $context -FileShareName <share-name> -FilePath "/" -Type Allow -Principal "testUser@contoso.com" -AccessRights Read,Synchronize -InheritanceFlags ObjectInherit,ContainerInherit

權限模型本身與任何 FSLogix 共用相同。Microsoft 建議的 ACL 是：CREATOR OWNER 對「僅子資料夾與檔案」擁有修改權限，管理員群組對「此資料夾、子資料夾與檔案」擁有完全控制權限，使用者群組對「僅此資料夾」擁有修改權限。新建的 Azure 檔案共用根目錄已經授與 NT AUTHORITY\Authenticated Users 可繼承的修改權限，以及 CREATOR OWNER 對子物件的完全控制權限，這比建議模型寬鬆，但足以用於試驗。共用層級 RBAC 與 Windows ACL 都會強制執行，以最嚴格者為準，因此共用層級的 Reader 即使擁有資料夾的完全控制權限也無法寫入。

如果需要在建立設定檔資料夾時就設定 ACL 而不借助任何工具，FSLogix 的 SIDDirSDDL 設定接受帶有 %sid% 預留位置的 SDDL 字串，並在建立使用者目錄時套用。

步驟 5：工作階段主機設定

每台工作階段主機上有三個登錄區域：必須允許 Windows 擷取雲端 Kerberos 票證，Entra 憑證金鑰必須隨設定檔漫遊，而且 FSLogix 必須指向共用。請將這些內容烘焙進映像，或透過 Intune 派送。

雲端 Kerberos 票證擷取。使用 Intune 設定目錄中的 Kerberos > CloudKerberosTicketRetrievalEnabled 設定並設為 Enabled。Microsoft 特別指出要使用設定目錄而不是自訂 OMA-URI，因為 OMA-URI 方法在多工作階段主機上無法運作。群組原則的對應項目為 Administrative Templates > System > Kerberos > Allow retrieving the Azure AD Kerberos Ticket Granting Ticket during logon（較舊的組建標示為「Allow retrieving the cloud kerberos ticket during the logon」）。登錄形式：

reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters /v CloudKerberosTicketRetrievalEnabled /t REG_DWORD /d 1

需要重新開機或重新整理原則。設定之後，除非加入主機對應領域的對應，否則主機將無法再存取使用 AD DS 驗證的儲存體帳戶；如果兩者並存，請為每個 AD DS 帳戶設定 Define host name-to-Kerberos realm mappings 或 ksetup /addhosttorealmmap <storageaccount>.file.core.windows.net <REALM>。

憑證金鑰漫遊。讓憑證管理員中的金鑰屬於正在載入的設定檔，而不是使用者第一次接觸的那台主機：

reg add HKLM\Software\Policies\Microsoft\AzureADAccount /v LoadCredKeyFromProfile /t REG_DWORD /d 1

FSLogix 設定。在 HKLM\SOFTWARE\FSLogix\Profiles 下，Microsoft 的設定設定檔容器指引如下：

$VHDLocations = "\\<storage-account>.file.core.windows.net\<share>"
New-ItemProperty -Path HKLM:\SOFTWARE\FSLogix\Profiles\ -Name Enabled -PropertyType dword -Value 1 -Force
New-ItemProperty -Path HKLM:\SOFTWARE\FSLogix\Profiles\ -Name VHDLocations -PropertyType string -Value $VHDLocations -Force
New-ItemProperty -Path HKLM:\SOFTWARE\FSLogix\Profiles\ -Name DeleteLocalProfileWhenVHDShouldApply -PropertyType dword -Value 1 -Force
New-ItemProperty -Path HKLM:\SOFTWARE\FSLogix\Profiles\ -Name FlipFlopProfileDirectoryName -PropertyType dword -Value 1 -Force
New-ItemProperty -Path HKLM:\SOFTWARE\FSLogix\Profiles\ -Name VolumeType -PropertyType string -Value vhdx -Force

將 RoamIdentity 保留為預設值 0；Microsoft 不建議使用舊式身分識別漫遊，且 26.01 版本已更新預設身分識別排除項目以符合 Entra 裝置身分識別指引。記錄位於 HKLM\SOFTWARE\FSLogix\Logging 下；LoggingEnabled 預設為 2（啟用所有記錄），LogFileKeepingPeriod 預設為 2 天，我在試驗期間會調高此值。

步驟 6：主機集區 RDP 屬性與單一登入

僅雲端使用者可以用使用者名稱和密碼登入已加入 Entra 的主機，但外部身分識別必須使用單一登入，而且 SSO 對所有人都是正確的預設選擇，因為它將無密碼驗證與第三方同盟一路帶進工作階段。SSO 設定包含五項工作：

1. 在 Windows Cloud Login 服務主體（應用程式識別碼 270efc09-cd0d-444b-a71f-39af4910ec45）上為 RDP 啟用 Entra 驗證。入口網站路徑：Microsoft Entra ID > Devices > Remote connection configuration > Windows Cloud Login，然後啟用 Entra ID 驗證通訊協定。在 PowerShell 中，將其 remoteDesktopSecurityConfiguration 上的 isRemoteDesktopProtocolEnabled 設為 true。
2. 透過在 Target device groups to enable SSO 下加入工作階段主機的動態裝置群組（最多 10 個群組）來隱藏同意提示。否則，使用者會被要求允許連線，而 Entra 會在 30 天內記住 15 台主機。
3. 只有在 AD DS 是您環境的一部分時才建立 Kerberos 伺服器物件。在純僅雲端建置中沒有 AD DS，因此此步驟不適用。
4. 檢視條件式存取（步驟 7）。
5. 在主機集區上，將 RDP 屬性 Microsoft Entra single sign-on 設為 Connections will use Microsoft Entra authentication to provide single sign-on，在 PowerShell 中即為 enablerdsaadauth:i:1。

RDP 屬性參考將 enablerdsaadauth（預設 0）記錄為 targetisaadjoined 的取代項。舊的 targetisaadjoined:i:1 仍適用於非 Windows 用戶端以及未加入 Entra、未混合式加入或未註冊的 Windows 裝置，但它將連線限制為使用者名稱與密碼，這就排除了無密碼與外部身分識別。如果先前的部署中設定了它，請在啟用 SSO 時移除。

對於沒有工作階段主機設定的主機集區，還需在資源群組層級將 Virtual Machine User Login 角色指派給與應用程式群組相同的使用者群組，否則使用者會通過代理驗證卻被 VM 拒絕。使用工作階段主機設定的主機集區不需要此指派。

步驟 7：條件式存取考量

Microsoft 的 AVD MFA 指引現在建議使用兩條對齊的原則而非一條：原則 1 以 Azure Virtual Desktop 應用程式（9cdead84-a844-4324-93f2-b2e6bb768d07）為目標，用於摘要與閘道驗證；原則 2 以 Windows Cloud Login 為目標，用於工作階段主機登入。兩者都要求 MFA；Every time 登入頻率僅在 Windows Cloud Login 上受支援。頻率不一致會導致工作階段中途出現提示。

在僅雲端 FSLogix 主機集區上，排除項目與納入項目同樣重要：

• 將 [Storage Account] .file.core.windows.net 從任何 MFA 原則中排除（步驟 2）。
• 切勿將 Azure Virtual Desktop Azure Resource Manager Provider 應用程式（50e95039-b200-4007-bc97-8d5790743a63）加入原則；它僅用於擷取摘要。
• 不要封鎖 Windows 365 應用程式（0af06dc6-e4b5-4f28-818e-e78e62d137a5）；即使使用者只有 AVD 資源，Windows App 也會向它進行驗證。
• 檢查任何以所有資源為目標並要求裝置合規性的原則。已加入 Entra 的工作階段主機可能無法符合為使用者端點撰寫的合規性原則。
• 為 AVD 使用者停用舊式的每使用者 MFA。若與條件式存取同時啟用，已加入 Entra 的主機會傳回「The sign-in method you’re trying to use isn’t allowed」。
• 如果不將登入限制為 Windows Hello 企業版等強式方法，請依照已加入 Entra 的主機文章所述排除 Azure Windows VM Sign-In 應用程式。

條件式存取需要 Entra ID P1 或 P2，且無法與安全性預設值並存。這也是 2026 年 5 月「預設無密碼」變更的交會點；我在 Entra ID 預設無密碼與治理整合中介紹過這些內容，值得與本文一起閱讀，因為啟用 SSO 的已加入 Entra AVD 主機集區正是密碼金鑰與 Windows Hello 企業版能夠一路貫通到桌面的環境。

外部身分識別：同一主機集區上的來賓

邀請承包商就是一般的 B2B 操作：在 Entra 系統管理中心，以至少 User Administrator 的身分前往 Microsoft Entra ID > Users > New user > Invite external user，輸入其電子郵件與顯示名稱，並在 Assignments 索引標籤中將其加入您的 AVD 使用者群組。來賓會以 emailaddress#EXT#@yourtenant.onmicrosoft.com 的形式出現在您的目錄中，使用者類型為來賓，且必須先兌換邀請，其他一切才會生效。

此後，來賓與群組中的任何其他成員一樣對待：應用程式群組指派、Virtual Machine User Login 角色、共用層級 RBAC 與目錄 ACL 都來自群組成員資格。第一位來賓登入前需要核對的事項：

1. 主機的作業系統組建。Windows 11 企業版 24H2 或更新版本且安裝 KB5065789 或更新，或 Windows Server 2025 且安裝 KB5073379 或更新。Microsoft 明確表示，外部身分識別的作業系統需求比僅雲端使用者更嚴格。
2. 已啟用 SSO。外部身分識別不能使用舊式使用者名稱加密碼的路徑；必須設定 enablerdsaadauth:i:1。
3. 用戶端。Windows、macOS、iOS、Android 上的 Windows App 或瀏覽器。在 iOS 與 Android 上，唯一支援的社交提供者是在 Authenticator 中設定為已連線帳戶的 Microsoft 帳戶。不支援一次性密碼登入。
4. 授權。Microsoft 的授權指引指出，來賓主租用戶中的授權不會賦予其在您租用戶中的 AVD 權限；請購買與員工同類的授權（例如 Microsoft 365 E3）並指派給您租用戶中的來賓物件。每使用者存取定價是針對外部商業用途（例如銷售 SaaS 應用程式），Microsoft 明確表示它不是啟用來賓帳戶的方式。
5. Microsoft 365 應用程式。只有在受邀帳戶擁有 Microsoft 365 Apps 授權且其主租用戶的條件式存取未封鎖時，桌面應用程式才能登入；否則來賓在工作階段瀏覽器中使用網頁版應用程式。
6. 雲端界線。AVD 端支援公用雲端與 Azure for US Government，但 FSLogix 與 Azure Files 端僅限公用雲端，且不支援跨雲端邀請。

來賓在共用上取得與成員相同的 %username%_%sid% 資料夾，這正是 GA 的意義所在：一個集區式主機集區，一種設定檔模型，內部與外部使用者並肩而行。

驗證

以從未登入過的測試使用者身分登入（或設定 DeleteLocalProfileWhenVHDShouldApply），然後：

• 在主機上執行 C:\Program Files\FSLogix\Apps\frx.exe list-redirects；第一行應將 \Users\<user> 對應到已掛接容器上的 \Device\HarddiskVolumeN\Profile。
• 在入口網站中開啟檔案共用，確認存在名為 <username>_<SID>（未啟用 FlipFlop 時為 <SID>_<username>）的目錄，其中含有 Profile_<username>.vhdx。
• 在工作階段中，klist cloud_debug 顯示 Cloud TGT，dsregcmd /status 回報 CloudTgt : YES。
• 檢查 HKLM\Software\FSLogix\Profiles\Sessions<SID> 中的 Status 為 0 且 Reason 為 0（容器已附加）。
• 在 Microsoft Entra ID > Monitoring & health > Sign-in logs 中依使用者篩選：Azure Virtual Desktop 與 Windows Cloud Login 項目都應顯示成功，並套用了預期的條件式存取原則。任何失敗項目都會告訴您是哪條原則封鎖了它。

疑難排解

先看文字記錄檔。FSLogix 會寫入 C:\ProgramData\FSLogix\Logs\Profile\Profile_<date>.log；搜尋 LoadProfile: <username>，追蹤執行緒識別碼，並閱讀所有 [ERROR:xxxxxxxx] 行。八位數代碼是 Windows 系統錯誤，可用 net helpmsg <decimal> 解碼。事件檢視器中有 Applications and Services Logs > FSLogix > Apps > Admin 與 Operational。FSLogix 支援工具可將所有內容打包以供開立案件。

對於儲存體端的診斷，AzFilesHybrid 模組（0.3.0 或更新版本）中的 Debug-AzStorageAccountAuth 會執行 Entra Kerberos 檢查：連接埠 445、Entra 連線能力、Entra 物件與 SPN、CloudKerberosTicketRetrieval 機碼、領域對應、管理員同意、兩個必要服務、Fiddler 代理以及加入類型。

何時仍應選擇加入 AD 的儲存體

我不會只因為可行就把混合式環境搬到 Entra Kerberos 儲存體。在以下情況，請在設定檔共用上保留 AD DS 或 Entra Domain Services 驗證：

• 使用者需要在工作階段內透過 Kerberos 或 NTLM 存取內部部署檔案伺服器、列印伺服器或整合式驗證的網頁應用程式；外部身分識別完全做不到這一點，而僅雲端使用者沒有內部部署帳戶。
• 您在 Azure Government 或 21Vianet 中執行，這些環境不支援僅雲端 Entra Kerberos。
• 您的身分識別是混合式，且工具鏈是 icacls、保留 ACL 的 Robocopy 或 Azure File Sync；混合式路徑可保留所有這些。
• 工作階段時長經常超過 10 小時，而您尚無法統一到 FSLogix 26.08；混合式加入的用戶端可以使用僅 Entra 用戶端無法使用的雲端信任緩解措施。

Azure Files 上的混合式 FSLogix 仍然完全受支援，GA 中沒有任何內容強制遷移。

應採取的行動

1. 依身分識別類型盤點使用者：混合式、僅雲端、來賓。目前沒有持續性設定檔的僅雲端使用者與來賓是首批候選對象。
2. 將試驗映像修補或重建為 Windows 11 24H2 並安裝 KB5079391 或更新版本（若來賓也會使用則為 KB5065789 或更新版本），並安裝 FSLogix 26.08。
3. 建立專用儲存體帳戶與共用，啟用 Entra Kerberos，授與管理員同意，加入 kdc_enable_cloud_group_sids，並將儲存體應用程式從 MFA 原則中排除。
4. 將預設共用層級權限設為 Storage File Data SMB Share Contributor，授與管理員 Elevated Contributor，並使用 Manage access 設定根 ACL。
5. 透過 Intune 設定目錄推送 CloudKerberosTicketRetrievalEnabled、LoadCredKeyFromProfile 以及 FSLogix 登錄值。
6. 在主機集區上啟用 SSO（enablerdsaadauth:i:1），設定 Windows Cloud Login，並移除舊指引遺留的任何 targetisaadjoined:i:1。
7. 建立兩條條件式存取原則，確認排除項目，並停用每使用者 MFA。
8. 讓一位僅雲端試驗使用者完成登入，以 frx.exe list-redirects 驗證容器，然後換成來賓重複一次。
9. 之後再重新檢視網域控制站汰除計畫，並為仍需要內部部署 Kerberos 的任何內容保留混合式共用。

我在 AVD 新功能系列中追蹤所有這些內容的每月變化。

需要幫手嗎？Big Hat Group 為美國與加拿大的組織提供 Azure Virtual Desktop 架構顧問服務，從身分識別與 FSLogix 健康檢查到完整的僅 Entra 主機集區建置。預約探索通話，一起梳理您的環境。

來源

• 使用 Microsoft Entra ID 在 Azure Files 上儲存 FSLogix 設定檔容器
• Azure Files 的 Microsoft Entra Kerberos 驗證
• 為 Azure Files 指派共用層級權限
• 為 Azure Files 設定目錄與檔案層級權限
• 設定 SMB 儲存體權限（FSLogix）
• 設定設定檔容器（FSLogix）
• FSLogix 設定參考
• FSLogix 版本資訊
• 使用記錄與診斷進行 FSLogix 疑難排解
• FSLogix 代碼及其意義
• Microsoft Entra Kerberos 簡介
• Azure Files 身分識別型驗證疑難排解（SMB）
• Azure Virtual Desktop 身分識別與驗證
• Azure Virtual Desktop 中已加入 Microsoft Entra 的工作階段主機
• 使用 Microsoft Entra ID 為 Azure Virtual Desktop 設定單一登入
• 支援的 RDP 屬性
• 使用條件式存取為 Azure Virtual Desktop 強制執行 Microsoft Entra 多重要素驗證
• Azure Virtual Desktop 授權
• 在 Microsoft Entra 系統管理中心新增 B2B 共同作業使用者
• Azure Virtual Desktop 的新功能