Azure Virtual Desktop Hybrid：Arc 伺服器架構指南

Azure Virtual Desktop 在大部分的生命週期裡都是純雲端服務：想用 AVD 的訊息代理（broker），就得把工作階段主機放在 Azure（或是最近才支援的 Azure Local）上。Azure Virtual Desktop Hybrid 打破了這條規則。控制平面留在 Azure，而工作階段主機可以在任何能連上 Azure Arc 的 Windows 機器上執行，實務上這代表您現有的 Hyper-V、VMware vSphere 或 Nutanix 叢集、一整個機櫃的實體 Windows Server，或是另一家雲端裡的虛擬機器。2026 年 5 月我撰寫AVD on Arc 伺服器公開預覽的文章時，它還只是個前景可期、僅供驗證用的版本。自 2026 年 9 月起它已正式發行，之後我持續在回答美國與加拿大 IT 團隊提出的同一組問題：到底什麼跑在哪裡、要花多少錢、相較於 Azure 託管的工作階段主機會失去什麼，以及該怎麼把它建好？本指南以目前的 Microsoft Learn 文件為參考來回答這些問題，並加入當客戶問我 Hybrid 是否該放進他們的架構時所運用的設計判斷。

Azure Virtual Desktop Hybrid 是什麼

Microsoft 的 Azure Virtual Desktop Hybrid 概觀把這個切分講得很清楚：「Azure Virtual Desktop 服務留在 Azure 中，而應用程式與桌面則託管於地端。工作階段主機必須啟用 Azure Arc。Azure Arc 擴充功能會安裝 AVD 元件並將裝置註冊到主機池。」責任界線同樣明確：「Microsoft 管理 Azure 中的 Azure Virtual Desktop 服務。您管理地端機器、網路與託管基礎結構。」

什麼跑在哪裡

四件事依序發生，而每件事的位置就是架構本身：

1. 您在自己的基礎結構上部署一台 Windows 虛擬機器或一台無周邊實體裝置。
2. 您安裝 Azure Arc Connected Machine 代理程式，它會把該機器以啟用 Arc 的伺服器身分投射到 Azure。
3. 您在該機器上執行 Azure Virtual Desktop Arc 擴充功能。擴充功能會安裝 AVD 代理程式軟體，並把機器註冊到主機池。
4. 使用者透過 Windows App 連線，和連到 Azure 中的工作階段主機完全一樣。

訊息代理、連線閘道、工作區、主機池、應用程式群組、診斷以及 Windows App 摘要都是 Azure 服務。Windows 工作階段、應用程式與使用者資料則位於主機所在之處。您不需要在地端安裝、修補或為任何 AVD 控制平面軟體做高可用性，這是它與在資料中心執行傳統 VDI 訊息代理最大的差別。

預覽還是 GA

截至撰寫本文時，此功能已正式發行。Azure Virtual Desktop 新功能頁面在 2026 年 9 月下將「Azure Virtual Desktop Hybrid」列為 GA，之前則是 2026 年 5 月標題為「AVD for hybrid environments with Arc-Enabled Servers」的公開預覽項目，並註明該版本不含佈建與電源管理。這項限制在 GA 時並未消失（下文詳述），但預覽期間僅限驗證主機池的限制已經解除。若想看逐週的歷程，我一直在 AVD 新功能系列追蹤每一次發行。

支援的作業系統與硬體

概觀中的支援表格值得牢記，因為它同時決定授權與密度兩方面的討論：

Hypervisor 由您選擇。Microsoft 的用語是「您偏好的、支援 Windows 虛擬機器的地端 Hypervisor」，而 Arc 代理程式自己的先決條件頁面將 VMware（含 Azure VMware Solution）、Azure Local 與「其他雲端環境」列為支援，並有一項明確排除：不要在已經跑在 Azure 中的虛擬機器上安裝 Arc 代理程式。

Hybrid 不做的事

這一段決定了大多數的設計。概觀原文：「Azure Virtual Desktop Hybrid 不會佈建或管理虛擬機器狀態，因此不支援下列功能：電源管理、自動調整、Start VM on Connect、工作階段主機設定。」緊接的一句把工作交給了您：「組織需自行使用 Hypervisor 工具、指令碼、合作夥伴解決方案或其他工具來部署與管理其地端工作階段主機。」

拿它和另一個地端選項 Azure Local 上的 Azure Virtual Desktop 比較一下。Azure Local 支援 Windows 11 企業版多重工作階段、由入口網站驅動的工作階段主機佈建與 Azure Marketplace 映像，但它需要 Azure Local 堆疊，而且「不支援作為 Azure 之外的獨立服務、在多雲環境中，或在其他啟用 Azure Arc 的伺服器上執行」。Hybrid 是反向的取捨：任何硬體、任何 Hypervisor，換來的是自己做生命週期管理並放棄多重工作階段。

先決條件與授權

Azure 與 Azure Arc 先決條件

部署文章在標準 AVD 需求之上疊加了 Hybrid 的需求：

• 訂用帳戶中必須註冊 Microsoft.DesktopVirtualization 資源提供者，建立主機池的人需要 Desktop Virtualization Contributor 角色。
• 工作階段主機必須能連到 Azure Virtual Desktop 必要 URL 與 Azure Arc 網路端點（兩者都在網路一節說明）。
• 每台工作階段主機都必須安裝並設定 Azure Arc Connected Machine 代理程式。
• 主機池必須是標準主機池、未透過 Azure 精靈新增任何虛擬機器，而且必須在身分識別索引標籤上指派受控識別。Microsoft 加了一則重要說明：「Azure Virtual Desktop Hybrid 不支援工作階段主機設定。」
• 主機池的受控識別需要對包含 Arc 伺服器的資源群組擁有 Reader 權限。Microsoft 警告：「如果受控識別對 Arc 資源群組沒有 Reader 存取權，未來的版本將阻止工作階段主機變成可用。」第一天就把它做好。

在 Arc 這一側，先決條件頁面要求註冊 Microsoft.HybridCompute、Microsoft.GuestConfiguration 與 Microsoft.HybridConnectivity 資源提供者，執行上線的人需要資源群組上的 Azure Connected Machine Onboarding（或 Contributor）角色。若群組原則自訂了「以服務身分登入」權限，NT SERVICE\himds 必須在清單中，否則代理程式無法啟動。

身分識別與加入需求

部署文章對加入類型有明確規定，這也是最容易讓 Windows Server 使用者感到意外的細節：

• Windows 用戶端工作階段主機（Windows 11 或 10 企業版）可以是 Microsoft Entra 已加入、Active Directory 網域服務已加入，或 Microsoft Entra 混合式已加入。
• Windows Server 工作階段主機必須加入 AD DS 或混合式加入。「由於依賴遠端桌面服務 (RDS) 授權伺服器，不支援僅限 Microsoft Entra ID 的加入。」

使用者本身必須存在於 Microsoft Entra ID 中。身分識別與驗證文章排除了只存在於 AD DS 的身分識別，支援透過 Microsoft Entra Connect 同步的混合式身分識別，也支援 Entra 已加入主機上的純雲端身分識別。Microsoft 建議對 Entra 已加入與混合式已加入的主機使用 Microsoft Entra 驗證的單一登入。若您仰賴智慧卡或 Windows Hello 企業版進行工作階段登入，它們使用 Kerberos，這代表用戶端需要能直達網域控制站或 KDC Proxy。對服務地端使用者的地端主機來說這通常已經成立；對遠端使用者則是一項設計事項。

授權：三層

Microsoft 把 Hybrid 授權概括為「使用者權利與 Azure Virtual Desktop Hybrid 服務使用者授權」。建立成本模型時我把它拆成三層：

1. 作業系統使用者權利。 就是上表。對 Windows Server 主機，請留意 RDS CAL 的軟體保證要求；沒有有效 SA 的一般 RDS CAL 不符合資格。通用的 AVD 授權文章補充，按使用者存取定價僅限外部商業用途，且不適用於 Windows Server 作業系統。
2. Azure Virtual Desktop Hybrid 服務費。 Azure Virtual Desktop 定價頁面將其描述為「在地端執行 Azure Virtual Desktop 工作階段主機的按使用者按月費用」，涵蓋管理與協調功能，並請您聯絡 Microsoft 帳戶團隊購買。我查看時沒有顯示任何金額，所以這裡不會引用。在建立商業論證之前先拿到書面報價。
3. Azure Arc 附加服務。 Azure Arc 定價頁面把核心控制平面（清查、管理、VM 自助服務）列為免費，附加服務啟用後才收費。Azure Policy 來賓設定與變更追蹤列為每伺服器每月 6 美元；Update Manager、Defender for Servers 與記錄擷取是獨立的計量項目。擁有有效軟體保證之 Windows Server 授權的客戶可免費取得 Update Manager、變更追蹤、機器設定與 Windows Admin Center，這點很重要，因為您的 Windows Server 主機很可能已為了符合 RDS CAL 規則而附帶 SA。

不變的是：Windows Server 本身仍需作業系統授權（定價頁面的註腳有寫），而 Windows 11 或 10 企業版的權利歸屬於使用者而非硬體。

網路與身分識別路徑

對外端點

一切都是對外的。必要 FQDN 與端點文章聲明「所有項目皆為對外；您不需要為 Azure Virtual Desktop 開放輸入連接埠」，Arc 的網路需求文章則說 Connected Machine 代理程式「透過 TCP 連接埠 443 安全地對外與 Azure Arc 通訊」。Microsoft 也明白表示，不支援 AVD 端點被封鎖的部署。

工作階段主機的 AVD 清單包含 login.microsoftonline.com（TCP 443）、*.wvd.microsoft.com（TCP 443，含基於 TCP 的 RDP 在內的服務流量）、*.prod.warm.ingest.monitor.core.windows.net 與 gcs.prod.monitoring.core.windows.net（代理程式流量）、mrsglobalsteus2prod.blob.core.windows.net（代理程式與並存堆疊更新）、數個 TCP 80 的憑證端點，以及服務流量用的 *.windows.cloud.microsoft、*.service.windows.cloud.microsoft 與 *.windows.static.microsoft。Arc 清單則加上 management.azure.com、*.his.arc.azure.com、*.guestconfiguration.azure.com、guestnotificationservice.azure.com、*.servicebus.windows.net、pas.windows.net、*.login.microsoft.com 與 download.microsoft.com，服務標籤為 AzureActiveDirectory、AzureTrafficManager、AzureResourceManager、AzureArcInfrastructure、Storage 與 AzureFrontDoor.Frontend。

在真實防火牆上實作時的兩點實務心得：

• AVD 清單中的兩個 Azure 架構位址 169.254.169.254 與 168.63.129.16 是 Azure 內部位址。在啟用 Arc 的主機上，執行個體中繼資料端點依設計就無法連線；Hybrid 疑難排解文章將此記錄為預期行為，擴充功能會回退到 Arc 混合式中繼資料服務。別花一個下午嘗試路由到它們。
• TLS 檢查會搞壞這一切。疑難排解文章記載了當 Proxy 改寫到 *.wvd.microsoft.com 的流量時，下載的代理程式 MSI 出現 Authenticode 簽章失敗以及 WebSocket 握手失敗。把 AVD URL 放進略過清單。

若 Proxy 團隊對 Arc 清單的長度有意見，Azure Arc 閘道可把 Arc 專屬的放行縮減到七個 FQDN，但要注意它僅適用於 Azure 公用雲端，且不建議用於需要 TLS 終止的環境。

RDP Shortpath 與延遲

Hybrid 在使用者體驗上的論點是延遲：工作階段主機就在使用者與應用程式後端旁邊。要得到這項好處，您會希望工作階段走 UDP。RDP Shortpath 一律先透過 Azure 中的 AVD 閘道建立 TCP 反向連線傳輸，再嘗試建立 UDP；若 UDP 成功就捨棄 TCP 路徑，否則 TCP 留作備援。

• 與主機在同一網路的使用者（下文的資料落地與分支機構模式）屬於受控網路情境：直接 UDP 連線，透過連接埠 3390 上的 RDP Shortpath 接聽程式，或透過不需輸入連接埠的 STUN。這正是 Hybrid 的亮點，因為 TCP 備援會把一條桌對桌的工作階段繞到 Azure 再回來。
• 遠端使用者使用公用網路的 RDP Shortpath：在 NAT 允許時透過 STUN 直接連線，否則透過 UDP 3478 上的 51.5.0.0/16 進行 TURN 中繼連線。Microsoft 指出 TURN 中繼依用戶端的實體位置選擇，若 UDP 被封鎖，工作階段會回退到 TCP。請允許從工作階段主機網路到該範圍的對外 UDP 3478，並避免基於 TCP 的 VPN、雙重 NAT 與強制通道。

FSLogix 設定檔的存放位置

把設定檔儲存體放在主機旁邊。Microsoft 自己針對地端 AVD 之 Azure Local 形態的指引，建議在與工作階段主機相同的網路上使用 SMB 共用，而對較大規模的部署則建議使用叢集外部的共用，讓儲存體與計算獨立擴展；架構中心參考補充，對設定檔共用而言「網路效能與延遲至關重要」。同樣的物理定律也適用於 Hybrid：卡加利的工作階段主機從加拿大中部的 Azure Files 掛接設定檔 VHDX，會替每次登入增加往返。

FSLogix 儲存體比較涵蓋 Azure Files、Azure NetApp Files 與儲存空間直接存取，而所有 FSLogix 容器都能在任何 SMB 共用上運作。對已加入 AD DS 的 Hybrid 主機，具 AD 整合 SMB 的 Windows 檔案伺服器叢集或 NAS 是自然的選擇。若您的 Windows 用戶端主機是 Entra 已加入且使用純雲端使用者，純雲端與外部身分識別的 FSLogix GA 移除了 Azure Files 對網域控制站的依賴，但請和上述的延遲考量一起權衡。

參考架構

元件

模式 1：由資料落地需求驅動的地端主機

受法規管制的組織（我最常在加拿大公部門、醫療照護與金融服務看到）把工作階段主機、設定檔共用與業務應用程式資料留在自己的資料中心，使用者大多在公司網路上。主機採 Windows Server，搭配附 SA 的 RDS CAL 以取得密度，加入 AD DS，並使用受控網路的 RDP Shortpath。對您的隱私部門坦白：Microsoft 的 Azure Local 指引指出，即使工作階段主機在地端，「某些客戶資料、診斷資料與服務產生的資料仍儲存在 Azure 中」，而 Hybrid 的訊息代理中繼資料位於您為主機池選擇的 Azure 區域。

模式 2：退出傳統 VDI 期間的硬體再利用

一家使用 Citrix 或 Omnissa Horizon 的中型組織，其 vSphere 或 Nutanix 硬體還有兩三年壽命，先換掉訊息代理：同一批虛擬機器啟用 Arc 並註冊到 AVD 主機池，Windows App 取代傳統用戶端，傳統控制平面則停用。隨著硬體老化，新容量改在 Azure 建置，切換以主機池為單位而非一次搬遷。依位置分開主機池；Microsoft 的 Azure Local 指引禁止在同一個池中混用 Azure 與 Azure Local 主機，為了負載平衡與疑難排解的清晰度，我對 Hybrid 池也採取相同的紀律。

模式 3：主機位於另一家雲端

Arc 代理程式可在「其他雲端環境」執行，並在發現 AWS 與 GCP 執行個體中繼資料時加以記錄，因此另一家雲端中的 Windows 虛擬機器也能成為 AVD 工作階段主機。用例比聽起來更窄：必須緊鄰該雲端中資料庫或授權伺服器的工作負載，或是把兩套桌面訊息代理整併成一套的組織。請為 TCP 備援路徑與 TURN 中繼建立輸出費用模型，並記住反向的排除規則：Azure 虛擬機器不啟用 Arc，而是以一般方式加入主機池。

逐步操作：從一台空白 Windows 機器到可用的工作階段主機

1. 準備主機池

在 Azure 入口網站建立標準的集區或個人主機池但不新增工作階段主機，在身分識別索引標籤上指派受控識別，建立或重用工作區與應用程式群組，並授予主機池身分識別對 Arc 資源群組的 Reader 權限：

$hostPool    = Get-AzWvdHostPool -Name "<HostPoolName>" -ResourceGroupName "<HostPoolResourceGroup>"
$principalId = $hostPool.IdentityPrincipalId

New-AzRoleAssignment -ObjectId $principalId -RoleDefinitionName "Reader" -ResourceGroupName "<ArcServersResourceGroup>"

2. 建置機器並上線到 Arc

用您平常的工具部署虛擬機器或實體伺服器。部署文章提到指令碼、Configuration Manager、Hypervisor 管理軟體與第三方工具，唯一的要求是「一台正在執行的 Windows 機器」。Arc 代理程式概觀中有兩條規則對 VDI 建置很重要：

• 您可以把 azcmagent 套件安裝進黃金映像，但不要在映像中執行 azcmagent connect。從已連線映像複製出的機器會共用同一個 Azure 資源識別碼，最後會中斷連線並出現 429 錯誤。
• 部署後用自動化逐台上線複製機。用 azcmagent show 確認 Agent Status 為 Connected 且 Tenant ID 欄位已填入；疑難排解文章把缺少租用戶識別碼列為阻擋註冊的硬性障礙。

3. 把主機註冊到主機池

產生註冊金鑰（有效期最長 27 天），並把權杖放入受保護設定來安裝擴充功能。入口網站路徑為 Azure Arc > Infrastructure > Machines > 您的機器 > Settings > Extensions > Add > Azure Virtual Desktop Hybrid，然後選擇訂用帳戶、資源群組與主機池。在 PowerShell 中，使用 Az.DesktopVirtualization 與 Az.ConnectedMachine 模組：

$expiresUtc = (Get-Date).ToUniversalTime().AddHours(24).ToString("yyyy-MM-ddTHH:mm:ss.fffffffZ")
$regInfo    = New-AzWvdRegistrationInfo -ResourceGroupName $HostPoolRG -HostPoolName $HostPoolName -ExpirationTime $expiresUtc
$token      = $regInfo.Token

$protectedSettings = @{ registrationToken = $token }

New-AzConnectedMachineExtension -Name 'Microsoft.AzureVirtualDesktop.CloudDeviceExtension' -ResourceGroupName '<ResourceGroupName>' -MachineName '<MachineName>' -Location '<Azure Region>' -Publisher 'Microsoft.AzureVirtualDesktop' -ExtensionType 'CloudDeviceExtension' -ProtectedSetting $protectedSettings

在 Windows Server 上，擴充功能會安裝遠端桌面工作階段主機角色，Microsoft 的提示很直白：若擴充功能「在 Windows Server 上安裝 RDSH 角色，將重新啟動工作階段主機」，因此請在映像中預先安裝該角色，以避免註冊期間重新開機。在 Windows 11 上它只是啟用 RDP。

4. 驗證

擴充功能在機器的擴充功能刀鋒視窗下回報 Succeeded。接著，依 Microsoft 的說法，「工作階段主機在主機池中回報為可用最多可能需要 15 分鐘」。從主機池檢查：

Get-AzWvdSessionHost -ResourceGroupName "<Resource Group>" -HostPoolName "<HOST POOL>"

把使用者指派到應用程式群組，用 Windows App 登入，並在連線資訊對話方塊中確認傳輸在您預期的情況下顯示為 UDP。若註冊失敗，C:\ProgramData\GuestConfig\extension_logs\Microsoft.AzureVirtualDesktop.CloudDeviceExtension\ 下的擴充功能記錄會告訴您六個階段中哪一個出了問題；搜尋 [Fatal]。Microsoft 記載的常見原因包括 Arc 代理程式設定中格式錯誤的 Proxy URL、過期或跨租用戶的註冊權杖（「不允許跨租用戶註冊」）、*.wvd.microsoft.com:443 上的訊息代理無法連線、執行 TLS 檢查的 Proxy，以及當池中仍殘留同名舊主機時出現的 NAME_ALREADY_REGISTERED。

營運

修補與映像更新

Microsoft 的工作階段主機 Windows 更新管理方法把世界分成就地修補與以映像為基礎的維護，而對 Hybrid 來說，這個選擇大致已替您做好。以映像為基礎的選項（工作階段主機更新、Azure Compute Gallery）依賴 Hybrid 所沒有的 Azure 佈建能力，所以您要就地修補，或透過自己的管線重建：

Azure Update Manager 會在客戶定義的維護時段內修補 Arc 連線的機器，對 Windows Server 池來說，這正是您想要的先清空再修補的節奏。對作業系統版本升級，Microsoft 的建議是從新映像部署新虛擬機器而非就地升級，所以即便每月修補已就位，也要保持黃金映像管線的活力。

監視

Azure Virtual Desktop Insights 需要主機池與工作區上的診斷設定、一個 Log Analytics 工作區，以及每台工作階段主機上帶資料收集規則的 Azure Monitor 代理程式。Azure Monitor 代理程式明確支援透過 Azure Arc 以 VM 擴充功能形式安裝在地端與其他雲端的機器上，因此 Insights 活頁簿對 Hybrid 主機同樣有效。請為 Log Analytics 擷取預留預算；代理程式本身免費。在 Arc 機器上加入 Azure Resource Health 警示：一台停止心跳超過 15 分鐘的 Arc 伺服器不是離線、被封鎖，就是代理程式已停止，這通常是 Hypervisor 主機出問題的第一個訊號。

調整規模與您失去的東西

沒有自動調整就代表沒有調整規模計畫在夜間關閉主機，個人桌面沒有 Start VM on Connect，也沒有動態自動調整為週一早上的尖峰建立主機。依尖峰規劃容量，用清空模式與主機池負載平衡設定進行維護，若需要以排程為基礎的電源管理，請把合作夥伴協調工具（預覽文章討論過合作夥伴生態系）視為解決方案成本的一部分。

與 Azure 託管工作階段主機的成本比較

因為 Hybrid 服務費未公布，而硬體成本只有您自己知道，我在此保持定性，但各個組成都有文件可查：

坦白的總結：當硬體已經付清且資料不能離開，或到地端後端的延遲佔主導時，Hybrid 勝出。當您需要彈性、多重工作階段密度或營運團隊很小時，Azure 勝出。若您在考慮改用按使用者計費的雲端電腦，我的 Windows 365 與 Azure Virtual Desktop 比較討論了這個分岔點。

何時不該使用 Azure Virtual Desktop Hybrid

• 您需要 Windows 11 多重工作階段密度。 使用 Azure 或 Azure Local；Hybrid 在用戶端作業系統上是單一工作階段。
• 您想要有彈性的成本。 沒有自動調整與 Start VM on Connect，代表您的地端主機在凌晨 3 點與早上 10 點的成本一樣。
• 您的主機是暫時性的。 Microsoft 的 Arc 先決條件寫明「不建議在短期（暫時性）伺服器或虛擬桌面基礎結構 (VDI) 虛擬機器上執行 Azure Arc」，因為 Arc 不會清理停止心跳的資源，而用相同名稱重建虛擬機器會與殘留資源衝突。Hybrid 適用於長期存在的主機；非持續性、登出即銷毀的設計是在與平台對抗。
• 您是純 Entra 環境卻使用 Windows Server。 Windows Server 主機需要 AD DS 或混合式加入。若目標是淘汰網域控制站，請使用 Windows 11 企業版主機，或把主機放到 Azure。
• 您的網路團隊無法放行這些端點。 Microsoft 不支援 AVD URL 被封鎖的部署，而對 *.wvd.microsoft.com 做 TLS 檢查會破壞註冊。
• 硬體本來就到了生命週期終點。 全部的價值在於再利用。若您得為此採購新伺服器，請先替 Azure 或 Windows 365 估價。

因應措施

1. 在簡報設計之前，先到 Microsoft Learn 的 Hybrid 概觀確認 GA 狀態與目前的限制；不支援清單（電源管理、自動調整、Start VM on Connect、工作階段主機設定）應放在第二張投影片。
2. 清查使用者權利。把 Windows Server 使用者（附有效 SA 的 RDS CAL 或 RDS 使用者 SL）與 Windows 11/10 企業版使用者（Microsoft 365 或 Windows Enterprise E3/E5、VDA）分開，並標記出您原本打算透過按使用者存取定價在 Windows Server 上服務的任何人，因為這個組合無法使用。
3. 向 Microsoft 帳戶團隊索取 Azure Virtual Desktop Hybrid 按使用者服務費的書面報價，並連同 Arc 附加服務與 Log Analytics 擷取一起加入成本模型。
4. 依主機池決定加入類型：Windows Server 用 AD DS 或混合式加入，僅對 Windows 用戶端主機考慮 Entra 加入。啟用 Microsoft Entra 驗證的單一登入。
5. 把防火牆變更當成一個整體提交：AVD 工作階段主機 FQDN、Arc 端點與服務標籤、到 51.5.0.0/16 的對外 UDP 3478，以及對 *.wvd.microsoft.com 的 TLS 檢查略過。在試驗主機上執行 Azure Virtual Desktop Agent URL Tool 來證明。
6. 註冊 Arc 與 Desktop Virtualization 資源提供者，建立具受控識別的標準主機池，並在第一台主機註冊之前授予該識別對 Arc 資源群組的 Reader 權限。
7. 把 Arc 代理程式與 RDSH 角色烘進黃金映像但不把映像連到 Arc；用自動化上線每台複製機，並驗證 azcmagent show 回報了租用戶識別碼。
8. 用擴充功能註冊一台試驗主機，等它變成可用，並同時測試一位區域網路使用者與一位遠端使用者，確認區域網路使用者取得直接 UDP 傳輸。
9. 把 FSLogix 共用放在與主機相同的網路上，並對照 Azure 託管基準量測登入時間。
10. 透過 Azure Monitor 代理程式擴充功能接上 Azure Virtual Desktop Insights，為 Windows Server 池排定 Azure Update Manager 維護時段，並在 Arc 機器上設定 Resource Health 警示。
11. 寫好退場計畫：隨著硬體汰換，哪些主機池要搬到 Azure 或 Windows 365，以及觸發條件是什麼。

想把上面的步驟變成可列印的試行關卡嗎？下載包含 20 項檢查的 Azure Virtual Desktop Hybrid 就緒檢查清單。

需要幫手嗎？Big Hat Group 為美國與加拿大的組織提供 Azure Virtual Desktop 架構與部署顧問服務，從為期兩週的 Hybrid 就緒評估到完整的傳統 VDI 退場。預約探索通話，一起聊聊您的環境。

參考來源

• Azure Virtual Desktop Hybrid 概觀，Microsoft Learn
• 在地端部署 Azure Virtual Desktop Hybrid，Microsoft Learn
• Azure Virtual Desktop Hybrid 工作階段主機上線疑難排解，Microsoft Learn
• Azure Virtual Desktop 新功能，Microsoft Learn
• Azure Virtual Desktop 必要的 FQDN 與端點，Microsoft Learn
• Connected Machine 代理程式網路需求，Microsoft Learn
• Connected Machine 代理程式先決條件，Microsoft Learn
• Azure Connected Machine 代理程式概觀，Microsoft Learn
• 使用 Azure Arc 閘道簡化網路設定需求，Microsoft Learn
• RDP Shortpath，Microsoft Learn
• Azure Virtual Desktop 身分識別與驗證，Microsoft Learn
• Azure Virtual Desktop 授權，Microsoft Learn
• Azure Virtual Desktop 定價，Microsoft Azure
• Azure Arc 定價，Microsoft Azure
• Azure Local 上的 Azure Virtual Desktop，Microsoft Learn
• Azure Local 的 Azure Virtual Desktop 參考架構，Azure 架構中心
• FSLogix 設定檔容器的儲存體選項，Microsoft Learn
• 在 Azure Virtual Desktop 中設定受控識別，Microsoft Learn
• 工作階段主機的 Windows 更新管理方法，Microsoft Learn
• Azure Update Manager 概觀，Microsoft Learn
• Azure Monitor 代理程式概觀，Microsoft Learn
• 啟用 Insights 以監視 Azure Virtual Desktop，Microsoft Learn
• 自動調整的調整規模計畫與範例情境，Microsoft Learn