Microsoft AZ-140: 工作階段主機映像與佈建 — 學習指南

    sysprep /oobe /generalize /shutdown /mode:vm
    ```

  - 驗證 Windows 已更新、任何使用者專屬的密碼都已清除，且事件日誌已輪替。不要將要擷取的映像加入網域。

- Azure Image Builder 與可重複的自訂
  - Azure Image Builder 使用宣告式管線來協調映像的建立，該管線可以新增軟體、套用基準、注入語言套件、執行 Windows Update，並發佈到 Azure Compute Gallery。
  - 強制可重複性：將 AIB 範本儲存在版本控制中，驅動參數化的建置，並將映像從開發 (dev) → 驗證 (validation) → 生產 (production) 的資源庫或區域進行晉升。

- Azure Resource Manager 範本、Bicep 與部署自動化
  - 將主機集區、應用程式群組、工作區、VM 擴展集和工作階段主機 VM 定義為程式碼 (as code)。將映像參考 (資源庫/定義/版本)、網路、大小和身分識別參數化。
  - 在需要 AD DS 網域加入的情況下，使用 Key Vault 參考來處理密碼。對於大型部署，預先驗證區域性的 vCPU 配額以避免佈建失敗。

- 範例：在 VM 佈建期間使用註冊權杖安裝 AVD 代理程式的 Bicep 片段

### 加入選項、註冊與網路/DNS 考量事項
身分識別加入與代理程式註冊必須與名稱解析和路由一併規劃。

- 在工作階段主機部署期間進行網域加入與 Microsoft Entra 加入
- AD DS 加入：支援 Windows 10/11 Enterprise multi-session 和 Windows Server。在您的部署工作流程中使用 “JSONADDomainExtension” 或原生的 domainJoin 屬性。將加入權限委派給具有受限 OU 範圍的服務帳戶。
- Microsoft Entra ID 加入：支援 Windows 11 Enterprise 和 Windows 11 Enterprise multi-session。這移除了對網域控制站的依賴，並可透過僅限雲端的身份識別與條件式存取來簡化裝置生命週期。在啟用前，請確保 AVD 用戶端與管理的先決條件都已滿足。
- Azure AD DS 加入：當使用受控網域時，請先將 VNet DNS 伺服器設定為 Azure AD DS 的 IP；否則，部署與加入將會失敗，因為工作階段主機無法解析該受控網域。

- DNS 與連線能力需求
- 確保 VNet DNS 指向能夠解析目標網域以及 Azure 服務紀錄的解析器。對於混合式 AD DS，請使用可透過對等互連或 VPN 連線的網域控制站 IP；設定多個 DNS 伺服器以維持彈性。
- 對於跨 VNet 的部署，請更新子 VNet 的 DNS 設定；進行 AD DS 加入時，請勿依賴預設的 Azure DNS。

- 工作階段主機代理程式的啟動程序與註冊權杖的使用
- AVD 代理程式配對 (Remote Desktop Agent Loader 和 side-by-side stack) 會使用有時效性的註冊權杖將 VM 註冊到主機集區。請在主機集區層級產生權杖，並在建置時或透過 VM 擴充功能將其注入。
- 當將現有 VM 上線到主機集區時，請在安裝代理程式之前產生一個新的註冊金鑰，以便 VM 能向 broker 註冊。
### 更新、安全性強化與驗證
將工作階段主機視為不可變動的；使用新映像檔擴展新主機，並將舊主機上的使用者移出後汰除。

- 更新策略：映像檔更新、熱修補 (hotpatching) 與復原計畫
- 映像檔更新：針對每月的品質與功能更新，產生新的 gallery 版本，進行驗證後再擴展。在解除配置並移除舊主機之前，使用「清空模式 (drain mode)」來驅離使用者。
- 熱修補 (Hotpatching)：僅適用於 Windows Server Azure Edition；它能減少修補期間的重新開機次數。Windows 10/11 Enterprise multi-session 不支援熱修補——請在您的映像檔管線中使用正常的累積更新，並視需要加上緊急的頻外修補程式。
- 復原 (Rollback)：在所有區域中至少保留一個前一版的生產環境映像檔版本。若偵測到問題，請從前一版本佈建新主機並重新指派容量。使用 gallery 的 ExcludeFromLatest 功能來暫緩有問題的建置版本。

- 映像檔安全性強化
- 基準：在映像檔管線中套用適用於 Windows 10/11 的 Microsoft 安全性基準或同等的 CIS 強化標準。使用 Defender for Cloud 和弱點評估進行驗證。
- 身分識別與存取：盡可能移除本機管理員，為任何本機管理員帳戶啟用 Windows LAPS，並對 AVD 登入強制執行 MFA/條件式存取。
- 磁碟與資料保護：使用平台管理或客戶管理的金鑰來進行磁碟加密。將 FSLogix 設定檔儲存在具備彈性的儲存體上；對於使用者數量龐大且有低延遲需求的場景，Azure NetApp Files 提供最高 IOPS 和最低延遲的設定檔儲存解決方案。
- 應用程式控制與攻擊面縮減：在可行之處啟用 Windows Defender Application Control，設定 ASR 規則，並部署 Microsoft Defender for Endpoint。
- 原則與漂移控制：使用 Azure Policy 來限制允許的 VM 映像檔和擴充功能；稽核偏差並封鎖流程外的變更。

- 在驗證主機集區中進行測試
- 維護一個小型的、獨立的驗證主機集區。將其設定為驗證環境，以接收 AVD 代理程式的預先發行更新，並在推廣至生產環境前，驗證新的映像檔版本、FSLogix 變更和 GPO。
- 在工作階段中衡量使用者體驗。例如，要快速分類感知到的顯示問題，可在「效能監視器」中檢查 RemoteFX Graphics Frames Skipped/Second 計數器，以隔離用戶端、網路或伺服器的瓶頸。

#### 實務問題情境
Siemens 需要在西歐和南印度地區，使用 Windows 11 Enterprise multi-session 主機來標準化 Azure Virtual Desktop。他們要求可重複的映像檔客製化、快速的部署、安全的復原，以及支援 Microsoft 365 Apps 和一個企業營運 (line-of-business) 附加元件的能力。一個受控的 Azure AD DS 網域已存在於歐洲的 hub VNet 中，Siemens 計劃在這兩個區域部署集區式 (pooled) 主機集區。

1) 準備名稱解析與加入網域的先決條件
 - 措施：將兩個 VNet 上的 DNS 伺服器設定為 Azure AD DS 的 IP，並確保 VNet peering 允許轉送 DNS 流量。
 - 原因：工作階段主機必須能夠解析受控網域才能加入 AD DS。先更新 VNet DNS 可以防止加入網域時發生失敗，並確保 Kerberos 和 LDAP 的解析正常。

2) 使用 Azure Image Builder 建立黃金映像檔
 - 措施：從 Marketplace 的「Windows 11 Enterprise multi-session + Microsoft 365 Apps」映像檔開始。使用 Azure Image Builder 加入 FSLogix、Defender for Endpoint、語言套件和安全性基準；然後執行 Windows Update 和 sysprep 一般化。
 - 原因：AIB 保證了一個可重複、可稽核的管線，能將漂移降到最低並產生一個密封的映像檔，確保每台主機都完全相同且符合規範。

3) 透過 Azure Compute Gallery 發佈與複寫
 - 措施：將擷取的映像檔以 1.0.0 版本發佈到 Azure Compute Gallery，並複寫到西歐和南印度。將 1.0.0 標記為最新版本；在準備 1.1.0 時，將 1.1.0 設定為 ExcludeFromLatest，直到驗證完成。
 - 原因：Gallery 複寫將映像檔放置在靠近主機建立位置的地方，以加快佈建速度，並透過最新版本和排除旗標提供受控的升級流程。

4) 使用 Bicep 自動化主機集區與 VM 佈建
 - 措施：將主機集區、應用程式群組和擴展計畫以程式碼形式部署。使用參數化的 Bicep 範本，從 gallery 版本建立工作階段主機，該範本會使用新產生的註冊權杖安裝 AVD 代理程式，並透過網域擴充功能執行 AD DS 網域加入。
 - 原因：基礎設施即程式碼 (Infrastructure as code) 確保了跨區域的一致性，使部署具備冪等性，並以最少的手動步驟簡化了向 broker 註冊的流程。

5) 在專用的驗證主機集區中進行驗證
 - 措施：在西歐建立一個小型的驗證主機集區，啟用驗證環境，並將一個試行群組導向該集區。衡量登入效能、FSLogix 行為和圖形計數器；解決發現的問題後，再移除 1.1.0 上的 ExcludeFromLatest 旗標。
 - 原因：及早偵測功能退化可以防止對廣大使用者造成影響，並讓 Siemens 只推廣經過驗證的映像檔。

6) 執行具備復原安全性的生產環境部署
 - 措施：在兩個區域從 1.1.0 版本擴展新主機。將舊主機置於清空模式 (drain mode)，在工作階段結束後解除配置並移除它們。保留 1.0.0 版本可用兩個發行週期。
 - 原因：藍綠部署 (Blue-green) 風格的替換方式可避免就地更新造成的漂移，並在問題出現時，能透過從前一版映像檔佈建來實現即時復原。

7) 持續強化與治理
 - 措施：套用 Azure Policy 來限制允許的映像檔和必要的擴充功能，啟用 Defender for Cloud 的建議，並將 FSLogix 設定檔儲存在 Azure NetApp Files 上以獲得可預測的高效能。
 - 原因：持續的治理和高效能的設定檔儲存，能在維持安全狀態的同時，大規模地維持使用者體驗。

---

← [網路、連線能力與傳輸](/tw/posts/az-140-networking/)  ·  [所有領域](/tw/posts/az-140-study-guide/)  ·  [FSLogix、設定檔與使用者資料](/tw/posts/az-140-fslogix-profiles/) →

**[練習這些題目 →](/tw/kb/microsoft/)**  ·  **[在 ExamRoll.io 上限時練習 →](https://www.examroll.io/?utm_source=guide&utm_medium=referral&utm_campaign=az-140)**