我接手的每一個 Azure Virtual Desktop 環境都有同樣兩個問題：沒人說得出工作階段主機來自哪個映像版本，而上一輪修補是靠逐台登入 30 台虛擬機器完成的。這篇指南就是我用來取代那種做法的流程。它涵蓋映像裡該放什麼、如何在 Azure Compute Gallery 中建置並版本化映像、如何用工作階段主機更新或經典的「排空再汰換」模式推送、建置出錯時如何回復、每一步實際需要多久，以及 Spot VM 和暫時性 OS 磁碟在成本全貌中的位置。文中所有內容都對照了內文連結與「來源」一節所列的 Microsoft Learn 頁面。

映像策略：資源庫映像還是自訂黃金映像

你有兩個起點。第一個是 Windows 11 Enterprise 多工作階段的 Azure Marketplace 映像，Microsoft 會在安全性修補程式發行後每月更新，而且預先安裝了 FSLogix。含 Microsoft 365 Apps 的版本大約在每月第三週中段上架。如果你的企業應用程式能透過 Intune 乾淨地安裝，你完全可以只用 Marketplace 映像，整個跳過映像管線。

第二個是自訂映像。Microsoft 的黃金映像指南將它描述為一台從 Marketplace 建立、經過自訂、以 Sysprep 一般化再擷取的 VM。該指南建議生產環境使用 Azure Compute Gallery 而非獨立的受控映像，因為前者支援複寫與版本控管；它也直白地列出常見錯誤：不要在映像中安裝 Azure Virtual Desktop 代理程式、不要擷取已經加入主機池的 VM、執行 Sysprep 前先讓 VM 離開網域、不要對同一台 VM 擷取兩次，也不要從既有的自訂映像建立新的基礎 VM。每次都從 Marketplace 映像重新開始。

哪些東西屬於映像，哪些屬於 Intune 或 FSLogix

我的規則很簡單：映像裡放那些安裝緩慢、或必須在第一位使用者登入前就存在的東西。其餘一切都移到不必重建就能變更的層。

層放在這裡原因
映像（Compute Gallery 版本）作業系統版本、累積更新、Microsoft 365 Apps、含 WebRTC 重新導向器的 Teams、FSLogix 代理程式、體積大或難搞的企業應用程式安裝程式、Visual C++ 執行階段、Virtual Desktop Optimization Tool 的變更安裝緩慢、首次登入就需要、受益於經過測試的重建
Intune 或群組原則設定目錄原則、Defender 設定、憑證、小型系統內容應用程式、Windows Update 品質更新設定工作階段主機更新不會保留手動加入的檔案、登錄機碼或憑證，因此設定必須來自管理工具或映像
FSLogix 設定檔容器使用者設定檔、Office 快取、OneDrive設定檔在主機之間漫遊，刪除主機不會遺失任何東西
自訂設定指令碼必須在佈建時執行的最後一步調整由工作階段主機設定在每台新主機上執行

Intune 有兩點與映像有關。Intune 多工作階段文件指出，Intune 不支援已註冊裝置的複製映像，所以永遠不要註冊建置 VM。多工作階段的應用程式必須在系統內容中以「必要」方式指派，這恰好是判斷什麼該進映像的好準則：任何只能以使用者身分安裝的東西都該進映像，而不是放在 Intune。

Image Builder 與自訂映像範本，還是手動 Sysprep

手動建置對少數主機還行；一旦同一個月有兩位管理員建出不同的映像，就行不通了。Azure Virtual Desktop 入口網站中的自訂映像範本是 Microsoft 的解答。它包裝了 Azure VM Image Builder，可用 Marketplace、資源庫、受控映像或既有範本作為來源，執行內建指令碼（安裝並設定 FSLogix、Teams 最佳化、語言套件、時區重新導向、RDP Shortpath、螢幕擷取保護、停用 Storage Sense、套用 Windows 更新）以及你放在公開 URL 的自訂指令碼，替你執行 Sysprep，再把結果散發到 Compute Gallery 或受控映像。建置以使用者指派的受控識別在名為 IT_<ResourceGroupName>_<TemplateName>_<GUID> 的暫存資源群組中執行，出問題時要看的是 packerlogs 容器中的 customization.log。

如果你偏好程式碼，底層的 Image Builder 範本在 Bicep 或 JSON 中提供同樣的自訂器。有兩個預設值對規劃很重要：buildTimeoutInMinutes 預設 240 分鐘、最大 960 分鐘，Microsoft 建議 Windows 不要低於 60 分鐘。如果仍有重新啟動或安裝程式懸而未決，WindowsUpdate 自訂器可能以 0x80240016 失敗，所以在它前面放一個 WindowsRestart 步驟。Microsoft 的 AVD Image Builder 逐步解說也指出，Windows 的建置 VM 應為 Standard_D2_v2 或更大。

版本命名慣例與複寫區域

Azure Compute Gallery 有三個層級：資源庫、映像定義（發行者、供應項目、SKU、OS 狀態、Hyper-V 世代與安全性類型）和映像版本。映像版本名稱必須是 MajorVersion.MinorVersion.Patch，latest 會解析為最高的主要版本、次要版本、修補號。我採用把 Windows 版本與修補月份編進去的慣例，例如目前映像定義上 2026 年 11 月累積更新對應 2026.11.0，同月的 Hotfix 重建則是 2026.11.1。讓發行者、供應項目與 SKU 的值跟你起步的 Marketplace 映像一致，這樣在入口網站中作業系統版本一眼就能辨識，這是一項文件化的最佳做法。

關於複寫，Compute Gallery 概觀給了具體指引：生產映像至少保留三個複本、每並行建立 20 台 VM 增加一個複本、在支援的區域以 ZRS 存放版本、生產與測試使用不同的資源庫，並在不同區域保留兩個資源庫以供災害復原。AVD 文件補充說，工作階段主機更新希望目標映像至少有兩個複本，且不支援使用與主機池位於不同訂用帳戶的資源庫映像。複寫到其他區域「在某些情況下可能需要數小時」，這對後面的時程表很重要。

有三個安全設定值得從第一天就啟用。在版本通過驗證前設定 excludeFromLatest，這樣不會有任何東西從它自動部署。把 safetyProfile.allowDeletionOfReplicatedLocations 設為 false，這樣沒人能移除運行中主機所依賴的區域。替資源庫加上資源鎖定。如果你使用 Trusted Launch，請注意以 API 版本 2025-03-03 或更新版本建立的映像定義預設為 Hyper-V 第 2 代與 TrustedLaunchSupported，而預覽中的 Trusted Launch 驗證在版本被標示為有效前至少要多等一小時。

AVD 映像更新與主機池修補策略

策略問題歸結為建立主機池時的一個決定：標準管理還是工作階段主機設定。Microsoft 的主機池管理方法頁面明確指出這個方法之後無法變更，而且工作階段主機設定僅適用於集區主機池。我在 2026 年 6 月的 Azure Virtual Desktop 更新彙整中介紹過這些自動化主機池的推出；本節談的是維運細節。

自動化主機池的工作階段主機更新

具有工作階段主機設定的主機池帶有兩個子資源。工作階段主機設定描述主機應該是什麼：映像、VM 大小、OS 磁碟類型、安全性類型、網域加入、網路、可用性區域、來自 Key Vault 的管理員認證、標籤，以及選用的自訂設定指令碼。工作階段主機管理原則描述如何建立與更新主機：時區、批次大小（入口網站預設為 1）、登出延遲（預設 2 分鐘，可設定 0 到 60 分鐘）、登出訊息，以及是否刪除原始 VM。

當你變更設定並排程更新時，工作階段主機更新會執行以下步驟（Microsoft 的原文加上我的轉述）：

  1. 依名稱挑出第一批主機，向已連線的使用者送出通知訊息，並在登出剩餘使用者前等待設定的延遲時間。
  2. 把這些主機置於排空模式，並從主機池移除。Active Directory 電腦物件不會被刪除。
  3. 從更新後的設定建立相同數量的新 VM，命名為 SessionHostName-DateTime，但保留原始的作業系統主機名稱，因此加入網域的主機會繼承既有的電腦物件與群組原則範圍。
  4. 把新主機加入主機池並關閉排空模式。
  5. 刪除原始 VM。

批次開始前，會先單獨更新一台稱為初始主機的主機，以驗證端對端流程。若初始主機失敗，更新就會停止。Microsoft 自己的範例是 10 台主機、批次大小 3 的主機池：一台初始主機，然後三批各三台，全程至少有七台主機可用。你最多可以提前兩週排程更新，而設定指南指出每台工作階段主機約需 20 分鐘，同一批次並行執行。

PowerShell 路徑使用預覽版 Az.DesktopVirtualization 模組（5.3.0 或更新版本）。把設定指向特定的資源庫版本、調整原則並排程：

powershell
Update-AzWvdSessionHostConfiguration -HostPoolName 'hp-fin-prod' -ResourceGroupName 'rg-avd-prod' `
  -ImageInfoType 'Custom' `
  -CustomInfoResourceID '/subscriptions/<sub>/resourceGroups/rg-avd-images/providers/Microsoft.Compute/galleries/acg_avd/images/win11-ms-m365/versions/2026.11.0'

Update-AzWvdSessionHostManagement -HostPoolName 'hp-fin-prod' -ResourceGroupName 'rg-avd-prod' `
  -ScheduledDateTimeZone 'Mountain Standard Time' -UpdateMaxVmsRemoved 5 `
  -UpdateLogOffDelayMinute 15 -UpdateLogOffMessage 'Maintenance: save your work and sign out.' `
  -UpdateDeleteOriginalVM $true

Invoke-AzWvdInitiateSessionHostUpdate -HostPoolName 'hp-fin-prod' -ResourceGroupName 'rg-avd-prod' `
  -ScheduledDateTime (Get-Date '2026-11-07 22:00')

Get-AzWvdSessionHostManagementsUpdateStatus -HostPoolName 'hp-fin-prod' -ResourceGroupName 'rg-avd-prod' |
  Format-List PercentComplete, ProgressSessionHostsCompleted, ProgressSessionHostsRollbackFailed

工作階段主機更新取代的是過去做這件事的一整堆指令碼：設定排空模式的 Runbook、建置新 VM 的管線、刪除舊 VM 的清理作業，以及記錄哪台主機用哪個映像的試算表。它取代不了的是設定管理。Microsoft 的指引是，任何手動加到主機上的東西在更新後都會消失，因此它們必須存在於映像、Intune 或群組原則，或自訂設定指令碼中。文件還有兩條維運規則：更新期間停用主機池上的自動調整，否則更新可能因執行階段錯誤而失敗；如果你從既有工作階段主機建置新映像，擷取前要刪除 C:\packages\plugin，否則 DSC 延伸模組無法把新 VM 加入主機池。

標準主機池的經典輪替更新

標準主機池沒有上述任何功能，Microsoft 的比較表寫得很清楚：你得「使用自己既有的工具與流程，例如自動化管線與自訂指令碼」。模式與工作階段主機更新自動化的那套相同，只是由你來做：

  1. 以新映像版本向同一個主機池部署新的工作階段主機，使用為該主機池產生的註冊權杖。替它們取能分辨新舊的名稱。
  2. 把舊主機置於排空模式，讓新連線落到新主機，而既有工作階段留在原處。若已指派自動調整，先替舊主機加上調整計畫的排除標籤，因為自動調整會覆寫排空模式。
  3. 通知使用者，等待工作階段清空，或在維護時段將他們登出。
  4. 從主機池移除舊主機，刪除 VM、磁碟與網路介面卡。
powershell
Update-AzWvdSessionHost -ResourceGroupName 'rg-avd-prod' -HostPoolName 'hp-eng-std' `
  -Name 'avd-eng-07.corp.contoso.com' -AllowNewSession:$false

排空模式需要 Desktop Virtualization Session Host Operator 角色，切換後入口網站可能有約 60 秒顯示的是舊狀態。Nerdio Manager 之類的第三方工具會替標準主機池自動化同一套流程；如果你已經擁有它，就用它。如果你正在建立新主機池，請以工作階段主機設定建立，讓平台來做這件事。

映像內重建與就地修補

工作階段主機更新頁面指出，從更新後的映像汰換主機「符合在核心來源映像中管理更新的建議，而不是依持續重複的排程把更新散發並安裝到每台工作階段主機」。Microsoft 的安全性建議補充說應每月修補基礎映像。這就是策略：每月的累積更新隨新映像版本出貨，主機從該版本汰換。

就地修補仍有用武之地，那就是等不到下次建置的緊急安全性修正。Windows 11 Enterprise 多工作階段的文件化選項比大家預期的窄：

方法針對 Windows Enterprise 多工作階段的文件立場用途
Intune 設定目錄，適用於 Business 的 Windows Update 類別支援品質更新：使用時間、延後、期限與寬限期、暫停。不支援更新通道。在兩次重建之間讓 Entra 加入或混合加入的主機保持最新
Microsoft Configuration Manager有文件：以 OS SKU 175 為條件的查詢驅動一條使用 Windows 用戶端更新的自動部署規則已經執行 Configuration Manager 的混合加入環境
WSUS多工作階段 FAQ 確認可透過 WSUS 取得品質更新與功能更新隔離網路
Azure Update Manager支援的映像與自訂映像清單僅限 Windows Server；未列出任何 Windows 用戶端或多工作階段 SKU以 Windows Server 為基礎的工作階段主機
自動 VM 來賓修補不支援自訂映像；支援清單僅有 Windows Server不適用於多工作階段
功能更新（例如 24H2 到 25H2）集區主機池不支援就地升級永遠是新映像

功能更新那一列替集區主機池的爭論畫下句點：Windows 版本變更就是映像變更，沒有例外。Intune 也把多工作階段視為獨立的作業系統版本，所以建立品質更新原則時，請在設定目錄中以 OS edition == Enterprise multi-session 篩選，否則你會花一整個下午納悶為什麼什麼都沒套用。

建議節奏

節奏動作機制
第二個星期二，同一週從最新的 Marketplace 發行或你自己的基礎映像建置映像版本 YYYY.MM.0，包含當月累積更新、應用程式更新與 FSLogix自訂映像範本或 Image Builder 管線，散發到資源庫並設定 excludeFromLatest
三個工作日內在設定相同的測試主機池上驗證，然後清除 excludeFromLatest驗證主機池上的工作階段主機更新
接下來的週末維護時段把生產主機池分批輪替到新版本工作階段主機更新，或標準主機池的排空再汰換
緊急若下次建置還要好幾天，就替運行中的主機套用重大安全性修正設定目錄品質更新期限、Configuration Manager 或 WSUS
每年兩次以新的 Marketplace 映像為基礎建置，移到下一個 Windows 功能更新新的映像定義或版本，全數主機汰換
每季清除比最近兩個已知良好版本更舊的映像版本，檢視複本數量與區域資源庫的例行維護

AVD 映像版本控管與回復策略

當上一個映像版本還在時，回復很便宜；當有人為了省幾 GB 快照儲存體把它刪了，回復就很貴。至少保留最近兩個已知良好的版本，在映像定義的版本資訊中標示目前版本，並對生產所依賴的任何東西設定 BlockDeletionBeforeEndOfLife 或資源鎖定。

固定到上一個映像版本

永遠不要把生產主機池指向 latest。工作階段主機設定參照的是精確的版本資源識別碼，動態自動調整會依該設定建立新主機，所以固定版本能帶來可預期的主機與一次輕鬆可逆的變更。回復具有工作階段主機設定的主機池與向前輪替是同一個操作：以上一個版本的資源識別碼執行 Update-AzWvdSessionHostConfiguration，再排程一次工作階段主機更新。Microsoft 自身對回復的關注呈現在狀態物件的 ProgressSessionHostsRollbackFailed 欄位上，請盯住這個計數器。

工作階段主機更新如何處理失敗

文件給出了清楚的失敗模型。若初始主機失敗，更新會在任何批次執行前停止。若某個批次失敗，你可以在入口網站或以 Invoke-AzWvdControlSessionHostUpdate -Action Retry 暫停、繼續、取消或重試；重試通常能清除大批次時偶發的 AgentRegistrationFailureGeneric 錯誤。暫停後兩週內未繼續的更新會被自動取消。無法復原的主機會被留在排空模式。重要的警語是，中途取消會留下一個混合的主機池，主機處於兩個作業系統版本甚至兩個網域中，Microsoft 要你盡快排程另一次更新以恢復一致。實務上這表示取消的更新之後應立刻接一次回復到上一版本的更新，而不是讓主機池半途而廢。另外要注意，失敗的更新在被取消前會阻擋刪除主機池，而且一旦排程，更新就不能編輯，只能取消後重新建立。

回復標準主機池

沒有工作階段主機更新時，回復就是輪替模式的反向操作：以上一個資源庫版本與新的註冊權杖部署主機，排空有問題映像上的主機，等工作階段清空，刪除它們。由於 FSLogix 保存著設定檔，而電腦帳戶只有在保留名稱時才會被重複使用，請採用能容忍兩代主機共存一天的命名方式。如果你還在標準主機池上用受控映像而非資源庫重建 VM，現在就是改用資源庫的時機，因為受控映像沒有可供回退的版本歷程。

更新 AVD 映像需要多久？

誠實的答案分三部分，其中只有一部分附有 Microsoft 的數字。下面的範圍是我在實務中看到的；文件化的錨點另行標出，其餘都是典型範圍，不是 Microsoft 的數字。

階段典型範圍影響因素文件化錨點
映像建置（Image Builder 或自訂映像範本）1 到 3 小時安裝程式的數量與大小、Windows Update 步驟、重新啟動、Teams 與 Office 安裝預設 buildTimeoutInMinutes 為 240，最大 960；Windows 建置不應低於 60
新版本的 Trusted Launch 驗證（預覽）1 小時或更久版本建立後的平台驗證至少一小時
Compute Gallery 複寫來源區域數分鐘；其他區域與複本數量需要 1 到數小時占用的映像大小、目標區域數、複本數「在某些情況下可能需要數小時」；向每個區域的首次複寫計收輸出流量費
在測試主機池上驗證1 到 2 個工作日你的應用程式負責人，而非平台無
工作階段主機更新，每台主機約 20 分鐘解除配置、建立、網域加入、代理程式註冊每台工作階段主機約 20 分鐘
工作階段主機更新，整個主機池初始主機加各批次，每批約 20 分鐘主機數除以批次大小，再加登出延遲（0 到 60 分鐘）每個主機池一次只能有一個更新；最多提前兩週排程

一個推算範例（根據文件中的 20 分鐘數字推導，而非引用 Microsoft 原文）：一個 40 台主機、批次大小 5、登出延遲 15 分鐘的主機池，會先跑一台初始主機，接著八個批次。九輪各約 20 分鐘再加延遲，大約三個半小時，全程至少有 35 台主機可用。批次大小減半，時段加倍；批次大小加倍，時段減半，但會同時讓 10 台主機停擺，並提高代理程式註冊錯誤的機率。請依並行餘裕而非急躁程度選擇批次大小。

端對端來說，「更新 AVD 映像需要多久」的務實答案是：當天完成建置與複寫，一到兩天驗證，再加一個兩到四小時的維護時段處理中型主機池。如果有人告訴你 30 分鐘，他講的是一台主機。

以 Spot 執行個體自動化 AVD 主機池：文件怎麼說

每個月都有人搜尋這個問題，所以這裡是文件化的立場。Azure Spot VM 以折扣價出售閒置容量，沒有 SLA；當 Azure 需要收回容量時，VM 會在提前 30 秒通知（透過 Scheduled Events 盡力傳遞）後被收回。收回原則是「解除配置」（預設，磁碟仍計費、配額仍占用）或「刪除」。B 系列與促銷大小被排除，Spot 有獨立的配額池，而且 VM 建立後無法轉為 Spot 或從 Spot 轉回。

在 Azure Virtual Desktop 這一邊，不論支援與否都沒有文件。主機池精靈裡沒有 Spot 選項，工作階段主機設定結構描述有 vmSizeId、diskInfo、securityInfo 和 diffDiskSettings，但沒有優先順序、收回原則或計費設定檔屬性，AVD 的「新功能」歷程中也沒有任何 Spot 項目。在 Microsoft Q&A 上，一位 Microsoft 員工回答 2024 年 4 月的問題時說，Spot 對 AVD「有點冒險」、「VDI 不是 Azure Spot VM 的有效工作負載」，而且產品團隊建議改用自動調整來控制成本。一位志工版主描述了唯一的變通做法：自己建立 Spot VM，加入目錄，再用註冊權杖把它註冊到標準主機池。

這留給你的空間是：

  • 標準主機池上的開發、測試與訓練實驗環境：可行，前提是你能接受工作階段在任務中途消失。使用 FSLogix 讓設定檔得以保留，把收回原則設為「刪除」以免為滯留的磁碟付費，並在入口網站的價格歷程檢視中挑選歷史收回率低的大小。
  • 非持續性的集區生產環境：這不是我會設計的方案。30 秒的通知比多數組織設定的登出延遲還短，使用者會遺失未儲存的工作。
  • 具有工作階段主機設定的自動化主機池：目前不可能；結構描述裡沒有地方可以表達它。

為了成本而「自動化主機池」的受支援方式是自動調整：標準主機池使用電源管理調整，負責開關主機；工作階段主機設定主機池使用動態自動調整，還會在最小與最大主機池大小之間建立與刪除主機。若你只想要「建立與刪除」的行為，把 Minimum percentage of active hosts (%) 設為 100。動態自動調整以目前工作階段主機設定中的映像建置新主機，這又是一個固定版本的理由。

成本槓桿：暫時性 OS 磁碟、保留項目、排空即解除配置與映像儲存體

暫時性 OS 磁碟。 AVD 的「新功能」頁面在 2025 年 10 月把暫時性 OS 磁碟支援列為公開預覽，2026 年 6 月列為可用，工作階段主機設定結構描述也公開了 diffDiskSettings，值為 option: Local 與 placement: CacheDisk 或 TempDisk。AVD 的必要條件頁面與 FAQ 尚未跟上，仍把暫時性 OS 磁碟列為不支援，所以投入前請先在你的區域確認。暫時性 OS 磁碟文件給出了限制：映像必須放得進 VM 大小的快取磁碟、暫存磁碟或 NVMe 磁碟，Trusted Launch 會保留其中 1 GiB，不支援停止並解除配置、快照、VM 擷取與 Azure Backup，重新安裝映像時資料會消失。最後這一點正是它只適合搭配 FSLogix 的集區主機、而且只能搭配刪除並重建（而非解除配置）主機的動態自動調整的原因。報酬是更快的重新安裝映像與更低的 OS 磁碟延遲；只有在選擇 SSD 基礎磁碟時才需支付基礎磁碟費用。

保留執行個體與節省方案。 AVD 成本指南把自動調整、Azure 節省方案與保留 VM 執行個體列為三大運算成本槓桿。保留 VM 執行個體為期一年或三年，只涵蓋運算部分（不含 Windows 軟體計量），是帳單折扣而非容量保證，而且自 2026 年 7 月 1 日起不再為部分 VM 系列銷售或續約，所以續約前請檢查你的系列。運算節省方案是每小時的美元承諾，可在不同大小與區域之間浮動，適合在動態自動調整下規模變化的主機池。用保留項目或節省方案涵蓋永遠開機的基準（作用中主機最低百分比），把彈性部分留在隨用隨付。

排空即解除配置。 自動調整的縮減階段會把主機置於排空模式，若啟用強制登出則在等待時間後登出使用者，然後解除配置。中斷連線的工作階段在合併計算中算作作用中，所以請搭配 Set time limit for disconnected sessions 原則，否則主機池永遠降不到零。工作階段主機更新也會尊重電源狀態：你可以更新一個所有主機都已解除配置的主機池，這是在夜間熄燈的主機池上輪替映像最便宜的方式。

映像儲存體。 Compute Gallery 本身免費；你為每個版本占用大小的快照儲存體付費，乘上複本數與區域數，再加上向每個區域首次複寫的輸出流量。Microsoft 的範例是一個 127 GB 的 OS 磁碟實際占用 10 GB，複寫到三個區域、每個區域兩個複本，以六個 10 GB 快照計費。把目前版本廣泛複寫、舊版本只留在一個區域、清除最近兩個已知良好版本以外的版本，並讓測試資源庫保持獨立，這樣清理指令碼就碰不到生產環境。

如果你的工作階段主機跑在 Azure Local 或已啟用 Arc 的伺服器上而非 Azure VM，映像建置管線相同，但推送工具不同；我在混合式 Arc 啟用伺服器預覽文章中談過。要追蹤影響這套流程的功能變更記錄，請關注 Azure Virtual Desktop 新功能系列。

該怎麼做

  1. 現在就替每個主機池決定管理方法。新的集區主機池採用工作階段主機設定；必須留在自訂管線上的維持標準管理。之後無法切換。
  2. 建立一個生產 Compute Gallery 與一個獨立的測試資源庫，每個都有一個映像定義，對應 Marketplace 的發行者、供應項目與 SKU，採用 Hyper-V 第 2 代與 TrustedLaunchSupported。
  3. 建立自訂映像範本或 Image Builder 管線，在修補星期二後兩天內產出 YYYY.MM.0，散發時設定 excludeFromLatest 直到驗證通過。
  4. 在生產區域至少設定三個複本、每並行建立 20 台主機增加一個複本、可用時採用 ZRS，並把 allowDeletionOfReplicatedLocations 設為 false。
  5. 把你在主機上手動設定的一切移到以多工作階段版本篩選的 Intune 設定目錄原則，或移到自訂設定指令碼。
  6. 對於工作階段主機設定主機池，一次設定好管理原則：依並行餘裕決定批次大小、10 到 15 分鐘的登出延遲加一則白話訊息，並把 UpdateDeleteOriginalVM 設為 $true。
  7. 對於標準主機池，把四步排空再汰換的流程寫成指令碼，包含自動調整排除標籤，並放進原始碼控管。
  8. 為緊急修正建立一條 Intune 品質更新原則，並接受功能更新永遠是新映像。
  9. 為每個主機池記錄回復命令，並每季在驗證主機池上測試一次。
  10. 對照 Q&A 的立場審視 Spot 需求，若業務堅持，就把實驗環境主機池導向標準管理並手動註冊主機。
  11. 為永遠開機的基準評估保留項目或節省方案，並確認你的 VM 系列在 2026 年 7 月之後仍可保留。
  12. 透過工作階段主機設定把映像版本寫進主機的 VM 標籤，讓「這台主機用的是哪個映像」在入口網站裡就有答案。

常見問題

更新 AVD 映像並推送到主機池需要多久？ 分三個階段預估。Image Builder 或自訂映像範本的建置在預設 240 分鐘逾時下執行，通常一到三小時完成。Compute Gallery 複寫到多個區域時可能需要數小時。接著工作階段主機更新約每台主機 20 分鐘，主機依批次汰換，因此 40 台主機、批次大小 5 的主機池大約需要三小時。規劃當天建置、下一個維護時段推送。

AVD 工作階段主機應該就地修補，還是每月重建映像？ Microsoft 的工作階段主機更新文件指出，在核心來源映像中管理更新是建議做法，其安全性指引也要求每月修補基礎映像。就地修補仍適用於兩次建置之間的緊急安全性修正。這類修正請使用 Intune 設定目錄的品質更新原則、Configuration Manager 或 WSUS，因為適用於 Business 的 Windows Update 更新通道與 Azure Update Manager 都沒有針對 Windows Enterprise 多工作階段的文件支援。

如何把 AVD 映像回復到上一個版本？ 至少保留上一個 Compute Gallery 版本，而且永遠不要讓生產環境指向 latest。對於具有工作階段主機設定的主機池，執行 Update-AzWvdSessionHostConfiguration 並帶入上一個版本的資源識別碼，然後再排程一次工作階段主機更新。對於標準主機池，從上一個版本建置新主機，用註冊權杖加入，排空有問題的主機，待工作階段清空後刪除。

可以把 Azure Spot VM 當作 AVD 工作階段主機嗎？ AVD 入口網站、工作階段主機設定結構描述和部署範本中都沒有文件化的 Spot 選項。Spot VM 沒有 SLA，而且會在提前 30 秒通知後被收回。一位 Microsoft 員工在 Microsoft Q&A 上表示 VDI 不是有效的 Spot 工作負載，並建議改用自動調整。如果你仍想在用完即丟的實驗環境使用 Spot，請自行建立 VM，並用註冊權杖把它們註冊到標準主機池。

工作階段主機更新與更新標準主機池有何差別？ 工作階段主機更新是以工作階段主機設定建立之主機池的原生功能。你修改設定、排程更新，服務就會依照工作階段主機管理原則分批排空、汰換並刪除主機。標準主機池沒有這項功能；你得用新映像建置新主機、以註冊權杖加入、排空舊主機，再用自己的指令碼或管線移除它們。管理方式在建立主機池時就已固定。

需要幫手嗎？Big Hat Group 為美國與加拿大的組織提供 Azure Virtual Desktop 架構與 Windows 365 顧問服務，從映像管線檢視到完整的主機池重新設計。預約一次探索通話，聊聊你的環境。

來源