Microsoft AZ-801: Azure Arc 與混合式伺服器管理 — 學習指南

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.

總覽

Azure Arc 將非 Azure 的伺服器——無論是地端或位於其他雲端——都納入與原生 Azure 資源相同的控制平面之下。已啟用 Arc 的伺服器會以第一級 Azure 資源的形式呈現，讓您可以套用 Azure Policy、管理擴充功能、使用 Azure Monitor Agent 收集遙測資料、透過 Update Management Center 協調修補作業，並利用 Azure Automanage 進行標準化。要能安全且一致地營運混合式機群，精通上線模式、代理程式與網路需求、角色型存取控制 (RBAC) 以及大規模治理至關重要。

已啟用 Azure Arc 的伺服器：上線、先決條件、網路、RBAC 與安全存取

上線 (Onboarding) 是透過安裝 Azure Connected Machine 代理程式 (azcmagent) 將機器連線至 Azure，此代理程式會將伺服器註冊到指定的訂用帳戶、資源群組和區域。

指令碼互動式上線 是最快的入門方式。從 Azure 入口網站產生「新增伺服器」指令碼並在本機執行。該指令碼會下載並安裝代理程式，然後使用裝置代碼流程 (device code flow) 向 Azure Resource Manager 驗證您的使用者身分，並建立 ConnectedMachine 資源。
服務主體式上線 是建議的生產環境方法。建立一個 Microsoft Entra 應用程式註冊，並賦予其最低權限的認證，也就是將 Azure Connected Machine Onboarding 角色範圍限定在目標資源群組。將服務主體 ID 和密碼傳遞給上線指令碼，以便透過您現有的工具 (如 Configuration Manager、Group Policy、Ansible 或自訂的自動化方案) 進行無人值守的大規模部署。
使用 Azure Policy 進行大規模啟用 著重於上線後的標準化。Azure Policy 無法在非 Azure 的機器上安裝 Arc 代理程式，但一旦機器連上 Arc，您就可以指派原則，自動為數千台伺服器部署必要的擴充功能 (如 Azure Monitor Agent、Dependency Agent、Custom Script) 和客體設定基準，並具備差異偵測與修復功能。經測試，這是將 Arc 伺服器上線至 Microsoft Sentinel 或 VM insights 等服務時，投入心力最少的方法。

支援的作業系統包括 Windows Server 2012 R2、2016、2019 和 2022，以及常見的企業級 Linux 發行版，例如 Ubuntu LTS (18.04+)、RHEL 7–9、SLES 12/15、Oracle Linux 7/8/9、CentOS 7 和 Amazon Linux 2。在進行大規模部署前，請務必查閱最新的官方文件，以確認精確的版本和核心需求。

代理程式的先決條件很直接：TLS 1.2、對外 HTTPS (TCP 443) 連線能力、足夠的磁碟和記憶體空間供代理程式快取和擴充功能使用、穩定的機器時脈，以及安裝所需的管理員/root 權限。對於代理伺服器 (proxy)，代理程式在 Windows 上支援系統代理 (WinHTTP)，並在兩個平台上都支援明確指定的代理。可使用

PolicyResources
| where type == "microsoft.policyinsights/policystates"
| summarize nonCompliant = countif(isCompliant == false) by resourceId

來設定 azcmagent 使用代理，或在 Windows 上利用

undefined

。如果您的環境使用 TLS 檢測，請將代理伺服器的受信任根 CA 憑證匯入機器的憑證存放區，這樣代理程式才能驗證 Azure 的端點。

防火牆和出口流量的允許清單 (allowlist) 必須允許對外的 443 埠連線至 Microsoft Entra ID (用於驗證)、Azure Resource Manager 以及區域性的 Arc 服務。如果您會使用 Update Management Center 和 Automanage，還需要允許連線至 Windows Update/Microsoft Update、您的 Linux 發行版套件庫，以及分發套件的內容交付端點。Arc 不需要任何對內的防火牆開口；所有控制流量都由伺服器發起到 Azure。

已啟用 Arc 的伺服器的 RBAC 遵循 Azure 的模型。使用內建角色來分離職責：

Azure Connected Machine Onboarding 允許透過服務主體建立 ConnectedMachine 資源，同時防止其擁有更廣泛的修改權限。
Azure Connected Machine Resource Administrator 可管理 Arc 伺服器資源及其擴充功能，而無需授予訂用帳戶層級的權限。
Azure Connected Machine User Login 和 Azure Connected Machine Administrator Login 在啟用透過 Azure AD 登入 SSH (Linux) 或 RDP/WinRM (Windows) 時，用來控制互動式存取。將 Arc 機器組織到能反映環境 (生產/非生產)、地理位置、業務單位或修補群組的資源群組中。在資源群組或管理群組層級設定原則、鎖定和角色指派的範圍，以簡化治理。

Arc 支援透過即時 (just-in-time) 通道技術，在沒有公用 IP 的情況下安全地存取 SSH。安裝 AADSSHLoginForLinux 擴充功能以啟用基於 Entra ID 的驗證，並將使用者/群組對應到本機的主體。擁有適當登入角色的授權使用者可以執行

undefined

，來建立一條連到伺服器 SSH daemon 的短暫、對外的 TLS 通道——無需對內連接埠、VPN 或堡壘主機 (bastion)。套用 Conditional Access 和 Privileged Identity Management 來為登入角色設定時間限制。

大規模的治理與設定：Azure Policy guest configuration 與 Automanage

Guest configuration 是 Azure Policy 針對 Arc 的客體內稽核與設定功能。內建的原則涵蓋了常見的基準，例如確保 Azure Monitor Agent 已安裝、稽核密碼原則、在支援的 Windows 上強制執行 BitLocker 或 FIPS 模式，或是在 Linux 上要求特定的 syslog facility。將這些原則大規模地指派給 Arc 範圍，平台就會視需要部署 Guest Configuration 擴充功能。若要使用自訂原則，請撰寫一個以 DSC 為基礎的 guest configuration 套件來表達期望的狀態 (例如，強化的 SSHD 設定或 Windows 防火牆規則)，將其發佈為自訂原則定義，然後再指派給您的 Arc 範圍。

修復任務能將稽核轉化為實際行動。具有 DeployIfNotExists 或 Modify 效果的原則可以建立或變更設定，而且您可以觸發隨選修復，讓現有的機器符合規範。對於重複發生的偏離，請啟用自動修復，讓原則引擎重新套用期望的狀態。在 Compliance 刀鋒視窗中，依原則、依機器、依範圍追蹤合規狀態，並從同一個 UI 將證據匯出給監管機構。

適用於已啟用 Arc 的伺服器的 Azure Automanage 能將「機器最佳實務」操作化。選擇適合開發/測試或生產環境的設定檔，平台就會將該機器納入一組精選的服務中：Azure Monitor (透過 AMA 和 VM insights 設定檔)、具有已定義維護時段的 Update Management Center、變更追蹤和詳細目錄、啟用 Microsoft Defender for Cloud 方案，以及核心作業系統安全性基準。Automanage 會持續偵測與所選設定檔的偏離，並在支援的情況下進行修復，同時提供對非 Azure 環境中任何需要手動介入項目的可見度。因為 Automanage 底層使用 Azure Policy，所以您可以大規模部署設定檔，並依賴相同的合規報告模型。

操作與監控：Update Management Center、AMA 與 DCR，以及 Arc 擴充功能

Update Management Center (UMC) 是適用於 Azure 和 Arc 機器的現代化、輕量級代理程式修補服務。它會持續評估遺漏的安全性與非安全性更新、按嚴重性和分類呈現合規性，並支援一次性與週期性的維護設定。定義維護時段，包含最長持續時間、重新開機行為 (永不、若需要、或一律)、前置與後置指令碼，以及使用 Azure 查詢和標籤的動態目標設定，如此一來，符合條件的新 Arc 機器就會自動被納入。對於 Windows，UMC 的來源是 Windows Update/Microsoft Update，或已設定的 WSUS；對於 Linux，則來自已設定的套件儲存庫。使用合規報告來按範圍追蹤修補百分比、檢視帶有詳細錯誤碼的失敗，並匯出資料以供稽核。因為 UMC 不依賴 Azure Automation 和舊版的 MMA，所以它是修補協調的未來策略方向。

Azure Monitor Agent (AMA) 是適用於已啟用 Arc 的伺服器的統一遙測管線。您不是在機器上寫死工作區，而是定義資料收集規則 (Data Collection Rules, DCRs) 來描述：

要收集什麼：Windows 事件日誌、Linux syslog 的 facility 和嚴重性、效能計數器，以及變更追蹤信號。
要傳送到哪裡：一個或多個 Log Analytics 工作區、Azure Monitor Metrics，以及可選的 Event Hubs。
如何轉換：在擷取前可選的資料塑形。在資源、資源群組、訂用帳戶或管理群組範圍關聯 DCR。這將設定與機器解耦，讓在工作區之間移動機器或在不同環境中收集不同資料變得輕而易舉。Arc 上的 VM insights 現在使用 AMA 搭配 VM insights DCR 設定檔來提升效能；若要取得相依性對應和程序拓撲，請安裝 Dependency Agent。

擴充功能是客體內功能的交付機制。從 Arc 伺服器的 Extensions 刀鋒視窗、CLI 或 Policy 來管理它們：

Microsoft Monitoring Agent (MMA) 是舊版，且對大多數解決方案來說已淘汰；只有在相依性尚未移轉到 AMA 時才使用它。
Azure Monitor Agent (AMA) 是目前日誌和計量的預設選項；請將它與 DCR 搭配使用。
Dependency Agent 提供服務和程序對應，在 VM insights map 的完整替代方案完成前為其所必需。
當 Policy 修復無法表達期望的變更時，Custom Script Extension (Windows/Linux) 可大規模執行指令碼以進行啟動載入或修正動作。
AADSSHLoginForLinux 和 AADLoginForWindows 可啟用 Entra ID 登入。其他常見的擴充功能包括 Defender for Endpoint 和設定管理用戶端。使用 Azure Policy 來確保必要的擴充功能存在且運作狀況良好。擴充功能的更新、復原和狀態都可在資源中和 Activity log 中看到，以供稽核。

使用 Azure Resource Graph 進行盤點、合規與報告

Azure Resource Graph (ARG) 查詢可傳回所有已啟用 Arc 的伺服器的近乎即時的盤點與合規狀態，且無需代理程式。使用它來驅動 CMDB 同步、標籤清理，以及為原則和修補選定範圍。常見的模式包括：

依作業系統和位置進行混合式盤點：

Resources
| where type == "microsoft.hybridcompute/machines"
| project name, resourceGroup, location, osName = properties.osName, osVersion = properties.osVersion, status = properties.status

Sentinel/AMA 準備就緒狀態：

Resources
| where type == "microsoft.hybridcompute/machines"
| extend hasAMA = todynamic(properties.extensions) has_any (x: x.name =~ "AzureMonitorWindowsAgent" or x.name =~ "AzureMonitorLinuxAgent")
| project name, hasAMA

基於標籤的報告與修補環圈目標設定：

Resources
| where type == "microsoft.hybridcompute/machines"
| project name, patchRing = tags.PatchRing, owner = tags.Owner
| summarize count() by patchRing

原則合規性彙總：

PolicyResources
| where type == "microsoft.policyinsights/policystates"
| summarize nonCompliant = countif(isCompliant == false) by resourceId

這些查詢是 Update Management Center、Automanage 指派和儀表板中動態範圍的基礎。在伺服器上線時標準化一組最小標籤集 (Environment, PatchRing, BusinessUnit, Owner)，以確保 ARG 保持可操作性。

實務問題情境

Contoso Ltd. 在兩個資料中心擁有 600 台地端的 Windows Server 和 Linux VM，由 Configuration Manager 和 Ansible 管理。領導階層要求標準化的監控、嚴格在週六維護時段內進行的每月修補、Sentinel 上線，以及安全的工程師 SSH 存取，且不暴露公用 IP。他們還希望為稽核人員提供合規證據，並將持續的管理工作降至最低。

準備最低權限存取

建立一個服務主體，其範圍限定在將包含 Arc 機器的 RG，並指派 Azure Connected Machine Onboarding 角色。這使得可以透過現有工具進行無人值守的上線，而無需授予廣泛的權限。原因：基於服務主體的上線方式具備擴展性，並滿足最低權限原則。

使用自動化將機器上線

在 Windows 的 Configuration Manager 和 Linux 的 Ansible 中，使用產生的 Arc 上線腳本與服務主體來安裝 azcmagent，並將每台伺服器註冊到適當的 RG (標記 Environment 和 PatchRing)。原因：重複使用現有的部署工具，實現快速、一致的推出，並嵌入標籤以供下游治理使用。

建立網路和代理伺服器出口

確保對 Entra ID、Azure Resource Manager、Arc 區域端點、Windows Update/Microsoft Update 及發行版儲存庫的出口 443 連線暢通。設定 azcmagent 代理伺服器設定，並在需要時匯入 TLS 檢測的根 CA。原因：確保代理程式和擴充功能的健康、更新擷取，並避免連線能力漂移。

使用 Azure Policy 客體設定強制執行基準

指派內建原則以部署 Guest Configuration 擴充功能、AMA 和 Dependency Agent。套用自訂的客體設定套件以強化 SSH 和 RDP 設定。對關鍵設定啟用自動修復。原因：原則能大規模地表達期望狀態、提供漂移偵測並修復偏差。

使用 Automanage 標準化操作

將 Automanage for Arc 的 Production 設定檔指派給生產環境的 RG，並將 Dev/Test 設定檔指派給非生產環境。審查任何針對非 Azure 資源標記為手動的項目。原因：Automanage 以最少的操作員精力持續應用最佳實踐。

設定監控與 Sentinel 上線

建立 DCRs 以收集 Windows SecurityEvent、Syslog 驗證設施和效能計數器到一個連接至 Microsoft Sentinel 的中央 Log Analytics 工作區。使用 Azure Policy 將 DCRs 與所有 Arc 機器關聯，並根據需要部署 Sentinel 解決方案套件。原因：AMA + DCR 將收集作業與機器解耦，而 Azure Policy 提供了在考試情境中驗證過的最省力的上線方法。

使用 Update Management Center 協調修補作業

根據每個 PatchRing 標籤定義每月重複的維護設定，包含 4 小時的週六時段、需要時重新開機，以及通知掛鉤。使用基於標籤的動態範圍，以便新機器能自動被納入。原因：UMC 提供輕量級代理程式、由標籤驅動的修補治理，並具備可稽核的合規報告。

啟用安全的 SSH 且無需公用 IP

透過 Policy 部署 AADSSHLoginForLinux，並透過 Privileged Identity Management 在目標 RG 上授予工程師 Azure Connected Machine User Login 權限。指示工程師使用 az ssh arc 搭配 Just-In-Time 啟用。原因：Arc 隧道技術消除了對公用入口或跳板機的需求，而 Entra ID 加上 PIM 提供了最低權限、有時間限制的存取。