Microsoft AZ-801: Windows Server 更新與修補程式管理 — 學習指南

By Laurynas Brazys · 7 August 2026 · #microsoft #az-801 #certification #exam-prep #study-guide

屬於 Microsoft Windows Server Hybrid Administrator Associate AZ-801 — 學習指南. 使用經過驗證的解答練習： Microsoft 考試中心, 或參加限時模擬考試： ExamRoll.io.

總覽

Windows Server 的修補程式管理橫跨地端與 Azure 託管的工作負載，結合了 WSUS 的精細核准工作流程、Windows Update for Business (WUfB) 原則的通道式部署、Azure 的大規模協調能力，以及健全的合規性報告。一個成功的策略需要標準化掃描來源、隔離測試與前導通道、在維護時段內控制重新開機，並持續清理中繼資料以保持效能的可預測性。混合環境管理員也必須了解新穎的 Azure 功能，例如 Update Management Center、VM 客體自動修補，以及適用於 Windows Server Azure Edition 的熱修補 (hotpatching)，以便在維持安全狀態的同時，將停機時間降至最低。

WSUS 架構與管理

一個設計良好的 WSUS 拓撲始於一台上游伺服器，它會從 Microsoft Update 同步中繼資料 (以及可選的內容)。下游伺服器則訂閱該上游伺服器。在複本模式 (replica mode) 下，下游伺服器會繼承上游的核准、電腦群組與設定，以實現集中式控制——這非常適合分支辦公室。在自主模式 (autonomous mode) 下，下游伺服器會接收更新中繼資料，但自行做出核准決策——這在區域團隊各自控制維護時很有用。同步作業應排定每日執行，同步選定的語言、產品與分類的中繼資料。對於大型部署，應設定 SSL (埠 8531) 來保護用戶端掃描流量與 WSUS 之間的複寫。

核准規則將通道 (rings) 付諸實行。自動核准規則可以為預備生產環境群組立即核准安全性更新 (以及可選的重大更新)，而其他通道則延遲數天或數週。對於大規模部署，請使用帶有期限的明確核准；期限會強制在指定時間前完成安裝，無論用戶端的「使用時間」為何。電腦群組定義了通道與工作負載層級 (前導、廣泛與關鍵伺服器)。群組指派可以是伺服器端或用戶端。透過伺服器端目標設定，新的用戶端會出現在 Unassigned Computers 中，然後由管理員將它們移至 WSUS 群組。透過用戶端目標設定，群組原則會設定

undefined

與

undefined

，讓機器在首次掃描時自行註冊到指定的 WSUS 群組——這更適合大規模且基於 OU 的動態配置。

用戶端 GPO 必須透過啟用

undefined

(更新服務與統計伺服器兩者皆要) 將 Windows Update Agent 指向 WSUS。設定

undefined

(例如，選項 4，自動下載並排程安裝) 與

undefined

來控制掃描的頻率。對於伺服器，設定

undefined

與

undefined

以避免干擾性的重新啟動；然後使用維護時段或協調工具來協調重新開機行為。如果環境中存在 WUfB 原則，請啟用

undefined

來防止用戶端繞過 WSUS。

持續的效能需要 WSUS 的健康維護。WSUS 清理精靈會移除被取代與過期的更新、刪除過時的更新檔案，並清除在設定的間隔內未曾聯繫 WSUS 的過時電腦。使用

undefined

將清理工作腳本化，並在匯入大量更新的同步作業後執行。

對於規模與穩定性而言，WSUS 資料庫維護是不可或缺的。過期的更新應該被拒絕；被取代的更新可以在其替代品於生產環境中達到穩定狀態後再拒絕。使用 Microsoft 的

undefined

定期對 SUSDB 進行重新索引並更新統計資料。不要依賴壓縮；應專注於索引的健康狀況。對於非常大型的環境，將 SUSDB 從 WID 遷移到完整的 SQL Server 執行個體，以利用進階索引、更佳的 I/O 與原生的 SQL Agent 排程功能。避免選擇過多的產品與語言——將範圍限制在您實際部署的項目，以減少中繼資料的變動與核准的負擔。

雲端協調更新：WUfB、Update Management Center、VM 客體修補與 Hotpatch

Windows Update for Business (WUfB) 透過基於通道 (ring) 的延遲與暫停機制，控制裝置何時直接從 Microsoft 的 CDN 接收功能更新 (Feature updates) 與品質更新 (Quality updates)。延遲原則 (透過 GPO 或 Intune) 可設定「選取預覽組建與功能更新的接收時機」以及「選取品質更新的接收時機」。功能更新的一般設定值為 0–365 天，品質更新則為 0–35 天。「暫停更新」功能會從指定的開始日期起，停止安裝功能或品質更新，最長可達 35 天——這在調查問題期間暫緩推出時很有用。通道是透過不同的原則指派來實作，每個指派有不同的延遲與暫停參數，隨著信心度增加，從 IT/試驗 (Pilot) 通道移至廣泛 (Broad) 通道。當您不需要 WSUS 核准，或偏好使用雲端內容交付與其保護措施時，請使用此方法。

Azure 中的 Update Management Center (UMC) 將 Azure VM 與已啟用 Arc 的伺服器的協調作業現代化。評估排程定義機器何時計算其遺漏的更新與合規性狀態——通常設定為每日執行，以確保儀表板資訊保持最新。修補原則定義要安裝的內容與時機：您可以選擇分類、包含/排除 KB、定義包含時區的維護期間、設定重新開機行為 (需要時重新開機、一律重新開機、永不重新開機)，並選取協調選項。動態範圍設定 (Dynamic scoping) 使用訂用帳戶、資源群組、位置或標籤，將原則附加到一組動態變動的機器上；當新增的機器帶有相符的標籤時，它們會被自動納入。這解決了大規模的治理問題，無需手動維護目標清單。對於可用性設定組 (availability sets) 與擴展集 (scale sets)，UMC 會錯開跨更新網域 (update domains) 的修補作業，以維持仲裁 (quorum) 與服務健康狀態。

自動 VM 客體修補會將「重大」(Critical) 與「安全性」(Security) 更新的選取和安裝工作委派給 Azure 平台。評估會依 Azure 管理的節奏執行；修補協調作業會遵循可用性結構，以將影響降到最低。重新開機設定可配置為「若需要」(IfRequired)、「一律」(Always) 或「永不」(Never)；只有在您有外部的重新開機協調機制時，才選擇「永不」。對於不僅需要安全性更新，或需要特定凍結期間 (blackout windows) 的伺服器，請使用 UMC 的排程修補部署，而非全自動模式。

熱修補 (Hotpatching) 可免除在受支援的 Windows Server Azure Edition 的 Azure 映像上，大多數每月安全性更新所需的重新開機。受支援的作業系統版本包含 Windows Server 2022 Datacenter: Azure Edition 及更新的 Azure Edition 版本。其服務模型會在「基準」(baseline) 月份與「熱修補」(hotpatch) 月份之間交替。一個「基準」月份會提供一個累積更新，這個更新會建立新的基準，並需要一次重新開機；隨後的「熱修補」月份則會套用記憶體內的修補程式，無需重新開機，大幅減少停機時間。請圍繞「基準」月份來規劃維護作業，並使用 UMC 或原則來確保每個週期至少套用一次基準更新，以整合無法進行熱修補的變更。

合規性報告與舊版 Azure Update Management

更新合規性報告必須同時滿足高階主管的可視性需求，以及營運上的根本原因分析。商務用 Windows Update 報告提供裝置層級和彙總的洞察，內容涵蓋更新狀態、安全防護保留、功能版本採用率以及失敗診斷。裝置會將必要的診斷資料傳送到與報告解決方案相關聯的 Log Analytics 工作區；可以透過 Intune、用於 Commercial ID 的 GPO 登錄機碼，或針對伺服器的 Azure Arc 來完成上線程序。使用內建的 Azure Monitor 活頁簿，依更新環、作業系統版本和更新類別來切分合規性資料；將關鍵圖表釘選到 Azure 儀表板，以供網路營運中心 (NOC) 檢視。

Azure Update Management (舊版) 結合了 Azure Automation 帳戶與 Log Analytics 工作區。機器 (Azure VM 和已啟用 Arc 的伺服器) 會將評估資料回報給 Log Analytics；排程部署會叫用 Automation Runbook，以在定義的維護時段內協調修補程式的安裝。可控制的參數包括分類、包含/排除的知識庫 (KB) 文章、前置和後置指令碼，以及重新開機原則。雖然已被 Update Management Center 取代，但舊版 Update Management 在既有的棕地環境中仍然很重要；遷移規劃應將排程、範圍和 Runbook 行為對應到 UMC 的修補原則和動態範圍設定。

修補程式的分類和嚴重性經常被混為一談，但兩者對原則設定都很重要。「安全性更新」是用於修補弱點的更新分類。在安全性更新中，來自 Microsoft 安全性回應中心的嚴重性等級分為「重大」、「重要」、「中度」和「低」。「重大」通常表示遠端程式碼執行或可廣泛傳播的蠕蟲化影響；「重要」通常包括權限提升或資訊洩漏；「中度」和「低」則反映了有限的可利用性或已有緩解措施。在 WSUS 和 Azure 原則中，建議優先將「安全性更新」(所有嚴重性) 迅速部署到試驗更新環，並在遙測資料確認穩定性後擴大部署範圍，同時根據業務對變更的容忍度來排程非安全性的「品質更新」。

最後，維持一個維運節奏。在驗證後定期拒絕過期和被取代的更新，每月執行清理精靈和 SQL 索引維護，核對在服務等級協定 (SLA) 內未聯繫 WSUS 或 Azure 的用戶端，並持續評估更新環的延遲和暫停邏輯。對於混合式機群，應為每台裝置標準化使用 WSUS 或 WUfB 作為掃描來源；不要在單一伺服器上混合使用。使用 Azure Arc 來統一治理，讓雲端和地端伺服器出現在單一的合規性架構中。

實際問題情境

Fabrikam, Inc. 公司營運著 600 台 Windows Server 機器：250 台位於地端，受到嚴格的輸出控制；250 台是託管分層應用程式的 Azure VM；還有 100 台是執行 Windows Server 2022 Datacenter: Azure Edition 的 Azure VM。他們需要可預測的週二修補、最少的停機時間、集中式報告，並且不要任何手動指定目標的作業。

建立掃描來源與更新環

對於地端伺服器，在資料中心部署一台中央上游 WSUS，並在分支機構部署兩台下游複本伺服器。透過 GPO 強制執行用戶端指定目標，讓伺服器自動註冊到 WSUS 的 Pilot-Servers、Broad-Servers 和 Finance-Servers 群組。這確保了確定性的內容核准，而無需掃描網際網路。
對於 Azure VM，使用 Update Management Center 並依標籤 Ring=Pilot 或 Ring=Broad 進行動態範圍設定，以避免手動維護清單。這會在雲端機器佈建時，自動將其與更新環的意圖對齊。為何如此：WSUS 滿足了輸出限制和精細核准的需求；UMC 提供了雲端規模的協調和標籤驅動的治理。

定義核准與延遲策略

在 WSUS 中，立即自動核准「安全性更新」給 Pilot-Servers；核准給 Broad-Servers 時設定 7 天的期限。非安全性的「品質更新」會先核准給 Pilot-Servers，並在驗證後再升級部署。
在 UMC 中，建立兩個修補原則：Pilot 在「修補星期二」的隔天安裝「安全性」和「品質」更新；Broad 將「品質」更新延遲 7 天。兩者都在 2 小時的維護時段內，於必要時重新開機。為何如此：更新環能及早發現迴歸問題，同時縮短弱點的修復時間。

在 Azure Edition 伺服器上啟用 Hotpatching

將適用的 Azure Edition VM 遷移到已啟用 Hotpatch 的映像檔，並將它們註冊到遵循基準月份的 UMC 修補原則中。確保每個基準週期至少套用一個基準。為何如此：Hotpatch 消除了 100 台 Azure Edition 伺服器上的大部分重新開機需求，在維持 SLA 的同時仍能套用每月的安全性修復。

為邊緣案例設定 VM 客體自動修補

對於低風險的公用程式 VM，啟用「VM 客體自動修補」(AutomaticByPlatform)，限制只套用「安全性更新」，並在營業時間之外於必要時重新開機。為何如此：對於不需要精細控制的系統，這能減輕維運負擔。

強化 WSUS 用戶端的 GPO

設定「指定內部網路 Microsoft 更新服務位置」、「設定自動更新」、偵測頻率，以及「不允許更新延遲原則導致對 Windows Update 進行掃描」。為伺服器設定「有使用者登入時不要自動重新啟動」。為何如此：防止掃描來源衝突和在服務時間內不必要的重新開機。

實作合規性報告

使用 Azure Arc 將所有地端伺服器上線到「商務用 Windows Update 報告」，並為 Azure VM 使用原生整合，將必要的診斷資料傳送到一個專用的 Log Analytics 工作區。發佈依更新環和環境區分的 Azure Monitor 活頁簿。為何如此：提供跨混合式資產的單一窗格報告，並能深入探究失敗診斷。

維護 WSUS 健康狀況與資料庫效能

每月執行 WSUS 清理精靈 (修剪過期/被取代的更新、過時的電腦)，在驗證後拒絕被取代的更新，並執行 WSUSDBMaintenance.sql 來重建 SUSDB 的索引。將產品/語言限制為 Fabrikam 實際部署的項目。為何如此：保持同步與核准操作的快速，減少用戶端掃描時間，並避免資料庫膨脹。