本文說明了在您的工作負載中,如何操作作業系統更新於 Windows 虛擬機(VM)上的建議方法。 建議的流程為您的工作負載中的 Windows 虛擬機提供一致、可擴展且受治理的補丁管理解決方案。 它讓你在預生產環境中驗證更新,然後再升級到生產環境。
有效的修補程式管理不僅僅安裝更新。 修補管理策略也需要一致的治理,確保虛擬機已接入修補管理解決方案,依照工作負載標準配置,並持續監控合規性。
備註
本文聚焦於 Azure 虛擬機器。 雖然 Azure 更新管理員 也支援支援 Azure Arc 的伺服器,但混合情境需要額外考量,且此處未涵蓋。
有關 虛擬機器擴展集 的資訊,請參閱 Azure 虛擬機 Scale Set 自動作業系統映像升級。
Azure 更新管理員
管理Azure Windows虛擬機Windows作業系統更新的建議方法是使用 Update Manager。 此服務提供集中排程與合規報告,並能為您的虛擬機執行分階段作業系統更新部署。 Update Manager 是透過安裝在你工作負載中每台虛擬機上的 sidecar Azure VM 擴充功能來運作。 Update Manager 不會自行架設或分發修補程式。 它控制並啟用每個虛擬機上的原生 Windows Update 代理程式(WUA)。
Update Manager 讓你的工作負載團隊能集中檢視環境中虛擬機的修補狀態。 你可以設定補丁目標和節奏,並啟用按需補丁推出。
Tip
更新管理器透過 WUA API 安裝 Windows 更新。 由於這些更新繞過了 Windows 設定所使用的 Windows Update 編排器工作流程,因此可能不會出現在>Windows Update>歷史紀錄中。 這是預期的行為。 要驗證更新安裝,請查看 Windows 事件檢視器 中的 WindowsUpdateClient 事件。
Azure 資源組織
Update Manager 不是 Azure 資源。 你不會將它部署在工作負載的訂用帳戶內。 它可在 Azure 入口網站使用,入口網站的體驗基於 RBAC 且不依賴訂閱。 你要維護維護設定、適用哪些作業系統修補、何時補丁,以及這些設定如何與你的工作負載虛擬機(VM)作為 Azure 資源的關聯。
每個維護配置都可以有單一排程,並可透過關聯針對任意數量的資源。 維護組態是區域資源。 使用單一維護設定和一組關聯,只包含同一區域和訂閱內的虛擬機。 如果你採用這種方法,所有環境都有獨立的維護設定資源,如果你的工作負載是多區域,或是工作負載不同部分有不同的更新排程,每個環境可能有多個資源。
將你的維護配置資源納入該環境工作負載的 IaC 中。 這種方式讓您能執行變更控制流程與安全部署,並提供災難復原選項。
虛擬機需求
Windows 虛擬機必須使用支援的自訂映像檔或 Azure Marketplace 映像檔。 不管來源是什麼,你都需要設定作業系統來支援更新。 建議的方法是透過虛擬機的 IaC 來設定所需的作業系統設定。 具體來說,請確保你的虛擬機至少具備以下設定:
windowsConfiguration: {
provisionVMAgent: true
enableAutomaticUpdates: true
patchSettings: {
patchMode: 'AutomaticByPlatform' // Turns off automatic updates in the OS; now platform triggers updates
assessmentMode: 'AutomaticByPlatform' // Scans for missing updates every 24 hours
automaticByPlatformSettings: {
bypassPlatformSafetyChecksOnUserSchedule: true // Allows Azure Update Management to honor defined schedules
rebootSetting: 'IfRequired' // Or 'Never' if required in your workload
}
}
}
Windows 訪客代理安裝了一個名為 Microsoft.CPlat.Core.WindowsPatchExtension 的 sidecar 擴充功能。 這個特權擴充功能會在你的虛擬機上執行,以取得排程並更新設定。 它也會呼叫原生 Windows OS 更新 API 來執行更新。 你不會把這個擴充功能定義為虛擬機 IaC 的一部分。 Update Manager 會自動安裝並維護其生命週期。
這個 WindowsPatchExtension 擴充功能不會覆蓋機器上的更新來源設定。 你仍然需要負責設定虛擬機的更新來源:
- Windows Update 儲存庫(Windows OS 及特定驅動程式)
- Microsoft Update 儲存庫(Windows 作業系統、特定驅動程式及特定 Microsoft 產品)
- 如果您的組織仍需要工作負載使用,則使用 Windows Server Update Services(WSUS)伺服器(現已棄用)
有關支援來源的詳細資訊,請參閱支援的更新來源、類型、Microsoft 應用程式更新及非 Microsoft 更新。
啟用自動評估,讓您的 合規報告 反映最新數據。 此功能顯示每個虛擬機相對於你的補丁基線的狀態,並在下一次排程執行前突顯新揭露的暴露。 評估只涵蓋正在執行的虛擬機。 被停止或解除配置的虛擬機不會被掃描。
這很重要
由於更新管理員直接調用 Windows 作業系統的原生功能,因此作業系統設定必須正確設定以支援補丁功能。
- 確保群組政策、Microsoft Intune 或其他組態管理工具不會覆蓋更新管理員在虛擬機上正常運作所需的作業系統設定。 關於特定設定值,請參閱 Azure 更新管理員 中的 Configure Windows Update Settings。
- 作業系統層級防火牆不得阻擋更新流量。
政策執行
你的工作負載也應該使用 Azure 原則,強制虛擬機在更新管理員中保持正確設定。 套用內建的 Azure 更新管理員 政策來防止設定漂移。 內建政策支援 DINE(deployIfNotExists) 及修改強制執行,以自動修復不合規的虛擬機。
關於以政策驅動的修補程式管理方法,請參見「使用政策啟用 Azure 虛擬機的定期評估與排程修補。 如果你的工作負載沒有使用 IaC 來部署和配置虛擬機,建議採用這個方法。
網路需求
對於有直接外接網際網路的 Azure 虛擬機,Windows Update 通常在沒有額外的網路允許清單的情況下運作,前提是訪客作業系統更新來源、DNS、代理伺服器、TLS 檢查及本地政策設定允許 Windows Update/Microsoft Update 流量。 然而,大多數工作負載在限制出站存取的鎖定虛擬網路中運作。 在這種情況下,你必須允許所有網路安全群組和防火牆之間,讓 Microsoft Update 端點的流量流過。
網路安全性群組
預設的更新來源,包括 Windows Update,都是基於 DNS 的,且不會發布穩定的靜態 IP 清單。 因此,對於網際網路託管的更新來源,連接於虛擬機網卡或其子網的網路安全群組必須支援網路出口流量至 TCP:443 和 TCP:80。 你應該進一步限制從出口防火牆內部的存取。 如果你的更新來自靜態 IP 位址範圍(例如本地端來源),你應該在網路安全群組中明確定義該出站目的地。
出口防火牆
您的輸出防火牆必須允許流向更新來源所使用之 FQDN 的流量。 如果你使用 Azure 防火牆 並使用Microsoft提供的更新來源,請使用WindowsUpdate FQDN標籤來允許對Windows Update端點的外發存取。 關於如何在網路路徑中設定其他出口防火牆的資訊,請參見 「配置防火牆」。 你應該只允許這些流量來自你的 Windows 虛擬機,而不是來自你工作負載中無關的子網。
將虛擬機與維護配置關聯
雖然你可以在維護設定和虛擬機之間建立靜態關聯,但建議改用動態範圍。 動態範圍根據資源群組、位置及標籤等屬性,決定哪些虛擬機與維護組態相關聯。 維護設定,而非動態範圍,決定安裝哪些更新及何時安裝。 動態範圍設定可自動納入符合條件的新虛擬機器,無需您管理每部虛擬機器各自的設定關聯資源。
使用動態範圍規則時,請遵循以下建議:
- 將 IaC 中的動態範圍規則納入你的工作量管理。
- 為避免跨環境依賴,僅包含你環境中的虛擬機,並根據需要在環境中複製配置與動態範圍規則。
- 使用標籤作為主要的關聯機制,並透過 Azure 原則 強制其使用。
設計分階段的修補時間表
典型的工作負載修補排程會採用分階段的部署排程。 在每月 Microsoft 更新釋出後,先對開發與測試虛擬機套用更新。 驗證完這些更新後,將相同的更新分類推廣到預生產區,然後在不同的維護視窗中推廣。
建立維護設定以定義重複性、維護視窗、更新分類及重啟行為。 接著建立動態範圍關聯,針對工作負載中的虛擬機執行例行的修補排程。
與 Patch Tuesday 對齊的排程通常允許幾天時間驗證,然後再部署生產環境。 由於 Microsoft 每月的安全更新通常在每月第二個星期二發布,建議的做法可能如下。 在這個例子中,目標虛擬機是透過一個動態範圍規則管理,該規則使用標籤。
| Environment | 排程 | VM 資源標籤 | 更新 | 重新啟動 |
|---|---|---|---|---|
| Development | 第二個星期二 2200-0000 |
PatchGroup
=
Backend 或 PatchGroup=Frontend |
關鍵 + 安全 | 如有需要 |
| 測試 | 第二個星期三 2200-0000 |
PatchGroup
=
Backend 或 PatchGroup=Frontend |
關鍵 + 安全 | 如有需要 |
| 生產後端(第一波) | 第二個星期六 2200-0100 |
PatchGroup=Backend |
關鍵 + 安全 | 如有需要 |
| 生產前端(第二波) | 下個星期天 2200-0100 |
PatchGroup=Frontend |
關鍵 + 安全 | 如有需要 |
處理更新時的並行處理
維護設定會同時啟動所有相關虛擬機的更新。 Azure 僅會依更新網域的順序逐一重新啟動同一可用性設定組中的虛擬機器。 這個例子中的 後端 和 前端 波次是依照層級分隔排程,而非冗餘容量,因此同一層級的每個實例都可以一起重啟,將該層級降到低於所需容量。
在每個生產層級內,將補丁拆分為容量保留波次,這些波次與你的可用性區域、更新域或工作負載定義的實例群組對齊。 每波使用不同的標籤值和維護配置。
考量部署的一致性
Update Manager 會在每次執行時重新評估一次。 因此,基於分類的排程可以在後續波次中選擇與不同知識庫(KB)文章相關的更新套件。 如果每一批 都必須 安裝完全相同的已驗證更新組合,請明確設定要納入的 KB 項目,而不要只依賴分類。
你可以透過 Update Manager REST API 查詢第一波的評估結果,然後更新後續波次的維護設定來自動化這個設定。
你為了達到完整的波次一致性所做的取捨,就是必須承擔相當高的協調編排複雜性。 如果你的工作負載能承受後面波次安裝不同於第一波更新包的風險,請使用基於分類的排程。
透過熱補丁減少重啟次數
重啟通常是修補計畫中最干擾的部分。 它們決定前表中的維護視窗大小及重啟行為。 在支援的映像檔中,熱補丁是透過修補執行程序的記憶體程式碼來安裝 Windows 安全更新,因此大多數月份的更新無需重啟即可生效。 Hotpatch 是 Windows Update 的擴充,因此 Update Manager 會使用你其他虛擬機使用的維護設定和動態範圍來安裝熱補丁。
如果你的工作負載對重啟很敏感,請採用支援熱補丁的作業系統 SKU 與設計:
- Hotpatch 僅適用於特定 Windows 映像檔。 你不能對任意自訂映像啟用熱補丁。
- 只有 Windows 的安全更新會被熱修補。 非安全更新、.NET 更新,以及驅動程式或韌體更新,在發布的幾個月內仍需重開機。 每季熱修補基準線,以及 Microsoft 為零時差漏洞修正而發布的任何計畫外基準線,也都需要重新啟動。 預留可容納一次重新啟動的維護時段。
處理「事前」和「事後」的問題
Update Manager 負責評估並安裝作業系統更新,但成功的修補過程可能會包含維護期間前後的活動,以優雅地處理必要的重啟或應用程式特定問題。 Update Manager 提供前 置事件與後續事件 ,供你用於工作負載自動化。 你會在工作負載架構中加入事件處理程序,比如 Azure 函式。 事件處理器會在排程修補執行前後回應 Azure 事件方格 通知。
使用 Update Manager 預先補丁活動來執行以下任務:
- 啟動一個已停止或重新配置的虛擬機。 被停止或重新配置的虛擬機無法修補,會被跳過。
- 確認備份恢復點是否可用。
- 驗證虛擬機與應用程式的健康狀況。
- 暫時抑制監控警報,以防止維護期間出現誤報。
更新安裝後,使用補丁後的活動來執行以下任務:
- 恢復監控。
- 執行應用程式與服務健康檢查。
- 請向 Microsoft Teams 頻道發布通知。
把事件網格和你的事件處理器運算當作工作負載資源來處理。 用 IaC 部署它們,並在不同環境間隔離。
準備隨時更新
Update Manager 支援在任何排程維護期間之外按需安裝修補程式。 此功能適用於緊急修補或關鍵的非週期修正,或在更廣泛的排程部署前驗證單一虛擬機的修補行為。 你可以直接從 Azure 入口網站或 Update Manager REST API 同時針對一個或多個虛擬機觸發按需更新。 工作負載團隊應該制定何時執行帶外更新的指引,以及該流程如何在整個工作負載中協調進行。
復原更新
更新管理員不提供作業系統補丁回滾。 套用修補程式後,沒有內建機制能透過更新管理員直接卸載。
如果你的工作負載需要支援「最後已知良好」狀態,可以在維護前建立快照或復原點。 自動化快照建立,讓它在每次補丁視窗前執行,確保在補丁套用前總有復原點存在。 或者,重新部署虛擬機而不使用修補程式,將有問題的知識庫補丁排除在部署中,然後重新套用更新。
這很重要
在正式環境啟用排程修補之前,先規劃好復原策略。
合規報告
Update Manager 會將評估與修補程式安裝結果推送到 Azure Resource Graph,該 Graph 會儲存待處理的更新 7 天,安裝結果則儲存 30 天。 Update Manager 內建合規報告和管理視圖,能讓您在整個環境中都能看到更新狀態。 這些儀表板讓管理員能監控修補程式的合規狀況、識別需要關注的機器,並從集中位置追蹤更新部署進度。
預設的工作簿會根據你的工作量呈現關鍵資訊:
- 機器狀態與配置的整體摘要
- 依嚴重程度與分類分類的待更新分類
- 排班表、維護配置及每個排程所附機器的摘要
- 過去安裝運行的歷史回顧,包括成功率與失敗案例
許多組織要求其應用團隊提供合規報告。 理想狀況下,您的組織已經使用 Update Manager 來進行追蹤,因為 Update Manager 入口網站的體驗和工作簿可以跨訂閱邊界運作,且你不需要在工作負載中提供任何自訂的修補程式狀態報告。
如果您或您的組織需要超出預設視圖的自訂報告,您可以自訂工作簿。 在您的工作負載的 IaC 檔案中加入客製化工作簿,以套用變更控制流程並提供災難復原選項。 另一種方法是透過 資源圖查詢提供所需的合規報告資料。
如果你的工作負載必須保留補丁歷史的時間比 Resource Graph 保留的時間還長,請建立一個流程,將資料匯出到你控制的儲存庫。
替代方法
如果你決定不採用排程、分階段更新管理器的方法來處理你的工作負載,請在設計自訂解決方案前評估 自動虛擬機訪客修補 。 如果你用這個選項,Azure 會幫你協調修補。 然而,若採用此方法,您將失去以下好處:
- 分階段推出。 更新不會透過開發、測試和生產波次推廣,因此你會失去驗證門檻。
- 維護時段控制。 Azure 會決定每個虛擬機時區的非尖峰時段何時執行修補。
- 更新分類控制。 僅套用關鍵與安全更新。 其他更新不會自動安裝。
貢獻者們
本文由 Microsoft 維護。 以下貢獻者撰寫了這篇文章。
主要作者:
- 泰德曼·李 |高級解決方案工程師
若要查看非公開的 LinkedIn 個人檔案,請登入 LinkedIn。
下一步
- 了解更新管理員的運作方式。
- 維護配置服務限制:檢視排程、資源關聯及動態範圍的限制。
- 排程執行順序與前後事件:了解活動前後的時程與取消行為,確保每個維護時段前有足夠準備時間。