Azure Stack Hub 补丁与更新：从服务策略到日志分析（下篇）

未经同意，请勿转载！

本文聚焦 Azure Stack Hub 一体机的补丁与更新全流程 ------ 服务策略、Microsoft 更新包 / Dell OEM 扩展包、版本控制、上传到存储、安装 / 恢复、日志分析、Dell Patch & Update Automation 工具，构成完整的更新操作蓝图。

版本基础 ：本文基于 azs-1901 至当前主流 azs 版本 的 Azure Stack Hub Operator 文档整理。不同 OEM 集成系统以及不同 azs 版本之间可能存在差异 ，当版本与本文表述不一致时，以当期版本 Azure Stack Hub Operator 文档 + 当期 OEM Support Matrix 为准。

修订说明：

本篇为 Azure Stack Hub 监控与更新三篇系列 · 补丁与更新篇首发版，基于内训材料《Azure Stack Hub 监控与更新》中"补丁与更新"章节整理，按四层原则做工程化改写。

[Azure Stack Hub 更新的全流程图](#Azure Stack Hub 更新的全流程图)
服务策略与版本支持窗口
[Microsoft 更新 vs Dell OEM 扩展包](#Microsoft 更新 vs Dell OEM 扩展包)
[Microsoft 软件更新类型](#Microsoft 软件更新类型)
更新包版本控制与命名规范
[更新包文件结构与 metadata.xml](#更新包文件结构与 metadata.xml)
更新研发与发布流程
更新顺序规则
[下载更新包：在线 vs 离线](#下载更新包：在线 vs 离线)
[上传更新包：管理员门户的 6 步流程](#上传更新包：管理员门户的 6 步流程)
开始更新：管理员门户操作
[开始更新：PowerShell 操作](#开始更新：PowerShell 操作)
[查看更新进度：PEP 与管理员门户](#查看更新进度：PEP 与管理员门户)
恢复失败的更新
[Dell OEM P&U：硬件侧的更新工具链](#Dell OEM P&U：硬件侧的更新工具链)
[Dell Patch & Update Automation 工作流](#Dell Patch & Update Automation 工作流)
分析更新日志
其他日志：Get-AzureStackLog
四个常见误判信号
四条更新场景红线
下篇小结：补丁与更新的工程化整合

1. Azure Stack Hub 更新的全流程图

L1 微软硬要求

Azure Stack Hub 的补丁与更新是一条严格的线性流程------它的每一步都是上一一步的前置条件。下面先给出完整流程图，再分章节展开每一段。

1.1 完整流程图

复制代码

[Step 1] 服务策略判断
   ├─ 当前版本是否在 N-2 支持窗口内？
   └─ 不在 → 升级到至少支持的最低版本
           ↓
[Step 2] 选择更新包类型
   ├─ Microsoft 软件更新（完整 / 快速 / 修补程序）
   └─ Dell OEM 扩展包（硬件固件 / 驱动 / HLH）
           ↓
[Step 3] 下载更新包
   ├─ 在线：Microsoft Update Catalog（默认）
   └─ 离线：aka.ms/azurestackupdatedownload
           ↓
[Step 4] 上传到存储
   ├─ 管理员门户 → 存储账户 → updateadminaccount → Blob 容器
   └─ 三件套：.exe / .bin / metadata.xml
           ↓
[Step 5] 启动更新
   ├─ 管理员门户：更新磁贴 → 立即更新
   └─ PowerShell：Install-AzsUpdate
           ↓
[Step 6] 监控更新进度
   ├─ 管理员门户：更新运行详细信息
   └─ PEP：Get-AzureStackUpdateStatus
           ↓
[Step 7] 处理失败 / 恢复
   ├─ 管理员门户：恢复按钮
   └─ PEP：Resume-AzureStackUpdate
           ↓
[Step 8] 日志分析
   ├─ 更新运行日志（JSON）
   └─ 全栈日志（Get-AzureStackLog）

L3 最佳实践 ：每一步操作都应被记录为运维工单------一体机更新是涉及全节点的破坏性变更，需要全链路审计。

2. 服务策略与版本支持窗口

L1 微软硬要求

Azure Stack Hub 要在支持配置内 ，必须在 Microsoft 明确指定的时间间隔内持续更新。

2.1 核心策略原则

维度	L0 版本事实	L1 微软硬要求
支持窗口	Microsoft 文档明确 "N-2" 保留窗口	客户必须维持在支持窗口内
更新延迟容忍	至多三个版本不更新	落后三个版本以上 = 不合规
不合规的后果	失去支持	失去支持（典型合同后果）
最小支持版本	由 Microsoft 公告	必须升级到至少最小支持版本

L2 微软实现

当前主流版本（azs-2XXX 期间）与之类似：

复制代码

180x PPT 示例（仅作演示）：
|  1809（最新）     |  ✅ 支持
|  1808（次新）     |  ✅ 支持
|  1807（最底限）   |  ✅ 支持（最小支持版本）
|  1805（过老）     |  ❌ 不支持

L3 最佳实践 ：管理员应定期查看 Microsoft 当期公告 ，确认一体机处于"最新 / 次新 / 最底限"三个支持版本之内。当前主流版本号以 Microsoft 公告为准------不要直接套用 PPT 里的 180x 演示。

2.2 落后三个版本以上的实际后果

L1 微软硬要求

当一体机落后三个版本以上时：

不提供厂商支持 ------ 微软 Support 团队可能不会接收你的 case 或仅接收"故障转移"类 case；
不接收新更新包 ------ 部分新版本可能要求"最低起点版本"（MinVersionRequired），若版本过老，甚至无法直接升级，必须先做过渡；
新功能 / 安全补丁无法获取 ------ 已知漏洞没有官方修复。

L3 最佳实践 ：建立月度版本审计机制------管理员每月初对照 Microsoft 当期公告，确认一体机版本号仍在 N-2 窗口内。

3. Microsoft 更新 vs Dell OEM 扩展包

L1 微软硬要求 + L2 OEM 实现

Azure Stack Hub 集成系统有两种类型的更新包，两者必须配套使用，缺一不可。

3.1 两种更新包的对照

维度	Microsoft 软件更新	Dell OEM 扩展包
提供方	Microsoft	Dell（OEM）
更新对象	Azure Stack Hub 软件栈（HRP / NRP / ACS / Windows Server Core 等）	缩放单元节点驱动程序、固件、HLH、MGMTVM、Secure Connect Gateway、网络交换机
部署入口	Azure Stack Hub 管理员门户	Azure Stack Hub 管理员门户
流程一致性	同样的"上传 → 安装 → 监控"流程	同样的"上传 → 安装 → 监控"流程
研发责任	Microsoft 研发	Dell 实验室 + Microsoft 联合认证
配套关系	通常先 Microsoft 更新，后 OEM 扩展	通常在 Microsoft 更新后做

3.2 Dell 提供的两类补丁

L2 Dell 实现

Dell 还提供独立的"补丁与更新"工具（Dell Patch and Update Automation / Dell P&U）：

Dell 工具	内容	下载位置
Dell P&U 工具（Dell Patch and Update Automation）	HLH / 戴尔网络交换机更新（包括 HLH 固件、HLH / MGMTVM OS、戴尔交换机固件）	Dell 支持按产品页面
Dell Customer Toolkit	服务器偏移配置 / 硬件监控实时清单 / 交换机 QoS 配置等 Dell 管理软件	Dell Customer Toolkit

L3 最佳实践 ：这两类补丁应在 Microsoft 更新完成后做 ------固件更新和 HLH 更新通常会在 Azure Stack Hub 更新后最后完成。

4. Microsoft 软件更新类型

L0 官方分类

Microsoft 软件更新按覆盖范围分为三类：

类型	说明	维护窗口
完整更新（Full Update）	更新缩放单元中的物理主机操作系统，需要更大的维护时段	长（数小时到半天）
快速更新（Express Update）	作用域有限，不更新基础物理主机操作系统，维护时段较短	短（数十分钟到 1 小时）
修补程序（Hotfix）	解决特定问题（通常是预防性或时间敏感）	极短（几分钟）

4.1 Microsoft 发布节奏

L0 版本事实

频率：Microsoft 每年定期发布多个完整和快速软件更新包，通常在每月的第四个星期二发布 。有些月份可能没有更新------这是 L0 事实，不是"漏发"；
修补程序：单独发布，不绑定月节奏。

4.2 三种类型的工程含义

L3 最佳实践

完整更新：计划在生产低峰期（如周末或节假日午夜窗口）执行；
快速更新：可在工作时间内执行（前提是业务容忍更广的服务降级）；
修补程序 ：通常由 Microsoft Support / OEM Support 主动推荐，应按建议立即执行。

5. 更新包版本控制与命名规范

L0 版本事实

Microsoft 更新程序包的命名约定非常关键------版本号既是身份识别，也是升级路径判断的依据。

5.1 命名规范

L0 版本事实

复制代码

产品主版本. YYMM. 次要版本. 内部版本号

例：1.2008.13.88
            ──┬──
              └ YY = 年（20 = 2020）
              ──|──
                MM = 月（08 = 8 月）
               ──|── ─┬──
                  次要版本 = 13
                ───|──  ─┬──
                       内部版本号 = 88

5.2 命名规则的解读

字段	含义	举例
主版本	当前固定为 1（Azure Stack Hub 主版本号）	1
YYMM	年 + 月，标识月份	2008 = 2020 年 8 月
次要版本	同月份内的迭代序号	13
内部版本号	同次要版本内的小修正	88

5.3 命名约定的工程含义

L3 最佳实践

2008 月份发布的更新包：1.2008.X.Y
2008 月份发布的修补程序 ：版本号递增次要版本和内部版本号，例如 1.2008.20.102 ------ 不要再开新的 YYMM，保持在同月；
跨月升级 ：1.2008.x.y → 1.2009.x.y ------ YYMM 必须单调递增；
完整文档参考 ：http://aka.ms/azurestackupdate

6. 更新包文件结构与 metadata.xml

L0 版本事实

更新包通常由三类文件 组成：.exe（自解压执行）、.bin（关联负载压缩包）、.xml（元数据）。

6.1 三类文件说明

文件类型	用途	内容
.exe	自解压包名称	包含更新的有效负载（如 Windows Server 最新累积更新）
.bin	关联负载压缩	与 .exe 文件配套的压缩负载
.xml	metadata.xml	包含更新的基本信息（发布者、名称、先决条件、大小、支持路径 URL）

6.2 metadata.xml 的关键字段

L0 版本事实

复制代码

</UpdatePackageManifest>
  <UpdateName>AzS Update - 1.1809.0.90</UpdateName>
  <Version>1.1809.0.90</Version>
  <PackageSizeInMb>2379</PackageSizeInMb>
  <Description>AzS Update 1.1809.0.90</Description>
  <KBLink>https://aka.ms/azurestackupdate</KBLink>
  <MinVersionRequired>1.1808.5.110</MinVersionRequired>

L1 微软硬要求 ：管理员必须检查 MinVersionRequired 是否 ≤ 当前一体机版本，否则不应上传------这会在上传时被系统拒绝。

6.3 metadata.xml 是审计源

L3 最佳实践

metadata.xml 是更新包的"身份证"------管理员在变更窗口前可读这个文件确认：

支持路径 URL（KBLink）------ 失败时应该去的文档；
包大小 ------ 与实际下载大小对比，验证传输完整性；
发布者 / 名称 ------ 验证未被篡改（不应使用非 Microsoft / OEM 签名的更新包）。

7. 更新研发与发布流程

L2 微软实现

7.1 研发流程

L2 微软实现 + L2 OEM 实现

复制代码

Microsoft                            Dell
  ┌──────┐                            ┌──────┐
  │ 构建 │  →  发布候选 (RC)  →       │ 部署&验证 │（在 Dell 实验室 10+ 节点规模）
  └──────┘                            └──────┘
  ┌────────────────────────┐
  │ 持续集成和验证          │
  └────────────────────────┘

7.2 多节点验证

L1 微软硬要求

PPT 强调**"10个多节点系统"**------意味着 Microsoft 在实验室部署 10+ 节点集群做集成验证。这是 L1 微软硬要求，意味着：

一体机上的更新已经经过多节点全栈验证，不是仅经过单元测试；
客户现场遇到的问题通常是边界场景，而不是基本集成问题；
管理员对常见更新失败应优先走诊断流程，而非直接怀疑包损坏。

8. 更新顺序规则

L1 微软硬要求

8.1 三条核心规则

规则	含义
N-2 维护	Microsoft Azure Stack 客户必须维护 N-2 Microsoft 版本以保持在受支持的配置中
顺序安装	Microsoft 修补程序和更新必须按顺序安装，包括之前和之后的修补程序
文档优先	客户必须遵循 Microsoft Azure Stack 文档中概述的说明

8.2 顺序安装的工程含义

L3 最佳实践

"按顺序安装"看似简单，但实际生产中容易踩坑：

场景 A ：当月修补程序 + 当月完整更新 ------ 哪个先？通常 当月修补程序先（因为它可能在前置基础上叠加）；
场景 B ：落后 3 个版本 ------ 跳过中间版本直接升级？绝对不可以------必须按顺序逐版本过渡；
场景 C ：OEM 扩展包与 Microsoft 更新冲突？通常 Microsoft 更新在先------但具体顺序以 Microsoft 当期文档为准。

8.3 Dell 端的对应流程

L2 OEM 实现

必须安装对应的 Dell 更新扩展包；
与使用管理门户的 Microsoft Azure Stack 更新使用相同的安装流程；
固件更新和 HLH 更新通常会在 Azure Stack Hub 更新后最后完成；
客户应遵守 Dell Technologies 支持网站上的"修补程序和更新指南"。

9. 下载更新包：在线 vs 离线

L1 微软硬要求 + L0 官方行为

9.1 在线（默认）

L0 版本事实

管理员门户会自动检查 Microsoft Update Catalog 是否有新更新；
当管理员门户显示有新更新时，客户端从 Microsoft 后台下载；
在线模式需要一体机具有出栈到 Microsoft Update 服务的网络能力。

9.2 离线 / 带外

L0 版本事实

适用于没有 Internet 或 Internet 连接较弱的环境：

下载工具 ：https://aka.ms/azurestackupdatedownload（Azure Stack Hub Update Downloader）
发行说明 ：https://docs.microsoft.com/en-us/azure-stack/operator/release-notes

L3 最佳实践 ：气隙 / 离线环境下应预先下载几个版本的离线包到本地存储介质，作为应急储备。

10. 上传更新包：管理员门户的 6 步流程

L1 微软硬要求

下载 Microsoft 更新包后，必须将更新包上传到 Azure Stack Hub 环境。OEM 更新包也需要上传。上传流程是标准的 6 步：

10.1 上传流程表

步骤	入口	操作	校验
1. 选存储账户	管理员门户 → "更多服务" → "数据 + 存储" → "存储账户"（或在筛选器框键入"存储账户"）	找到 `updateadminaccount` 存储账户	确认 account 名称正确
2. 进 updateadminaccount	在筛选器框中键入 `update`，选择 `updateadminaccount` 存储账户	进入存储账户详情	确认是 admin update 用 account
3. 进 Blob	在存储账户详细信息下，"服务" → "Blob"	进入 Blob 服务页
4. 创建容器	在 Blob 服务下选 "+ 容器"，输入名称（如 `Update-1802`）→ "确定"	容器创建成功	容器名规范（项目方自定）
5. 上传包	在容器内选 "上传"，浏览到更新包的 `.exe` 文件 → "打开" → "上传"	包文件上传完成	通知（右上角铃铛）显示"上传已完成"
6. 重复 4-5	同样路径上传 `PackageName.bin` 和 `metadata.xml`，或一次选择多个文件	三件套上传完毕	三个文件都在容器内

10.2 上传后的可见性

L0 版本事实

上传完成后，回到管理员门户的"更新"磁贴，磁贴会自动指示有可用更新。单击磁贴可查看新添加的更新包。

L3 最佳实践 ：上传完成后先在更新磁贴上确认包状态 = "Ready"，再开始安装。"Ready" 状态意味着元数据校验通过 + 文件完整性确认。

11. 开始更新：管理员门户操作

L1 微软硬要求

11.1 标准操作流程

步骤	动作
1	单击更新磁贴查看更新的详细信息
2	选择标记为"就绪"的包
3	右键单击该包 → 选择"立即更新"，或单击顶部附近的"立即更新"操作
4	安装过程中，可在"更新运行详细信息"区域中查看状态
5	在更新运行详情区，单击"下载完整日志"以下载日志文件（主动备份日志是 L3 最佳实践）
6	更新完成后，"更新"磁贴将显示更新的 Azure Stack Hub 版本号

11.2 关键观察点

L3 最佳实践

"就绪"状态 → 包已上传 + metadata 校验通过；
更新运行状态 → 管理员应在更新开始后 5-10 分钟内再次确认状态，避免"看似开始但实际卡在第一步"的误判；
完成后版本号 → 与 metadata.xml 的 <Version> 字段应一致------不一致说明包与元数据不匹配。

12. 开始更新：PowerShell 操作

L0 版本事实

如果管理员门户不可用、或者管理员偏好脚本化操作，可以用 PowerShell cmdlet 启动和监视更新状态。

12.1 四个核心 cmdlet 速查

Cmdlet	用途
`Get-AzsUpdateLocation`	检索 region 更新摘要（区域状态、可用更新数）
`Get-AzsUpdate`	列出 Azure Stack Hub 可用更新
`Install-AzsUpdate -Update "Update Version"`	应用指定更新，例如 `Install-AzsUpdate -Update Microsoft1.1907.0.10`
`Get-AzsUpdateRun`	检索特定 Azure Stack Hub 更新的进度和状态

12.2 安装示例

复制代码

# 列出可用更新
Get-AzsUpdate

# 安装指定更新
Install-AzsUpdate -Update "Microsoft1.1907.0.10"

# 检索更新运行进度
Get-AzsUpdateRun -UpdateName "Microsoft1.1907.0.10"

L3 最佳实践 ：版本号字符串格式应严格匹配 metadata.xml 中的 <UpdateName> 字段。错把 "1907" 写成 "1908" 会导致安装失败。

13. 查看更新进度：PEP 与管理员门户

L1 微软硬要求

可以使用 特权终结点（PEP） 监视 Azure Stack Hub 更新运行的进度，并在 Azure Stack Hub 门户不可用时从上一个成功步骤恢复失败的更新运行。

13.1 两套查看路径

路径	适用场景	推荐度
管理员门户（更新磁贴 → 更新运行详细信息）	日常 / 首选	✅ 建议使用
PEP（Get-AzureStackUpdateStatus）	管理员门户不可用 / 应急	⚠ 仅作为兜底

13.2 PEP 会话建立的标准步骤

复制代码

# 1. 配置可信主机
Set-Item WSMan:\localhost\Client\TrustedHosts -Value '<IP Address of Privileged Endpoint>' -Concatenate

# 2. 获取凭据
$cred = Get-Credential

# 3. 新建 PEP 会话
$pep = New-PSSession -ComputerName <IP_address_of_ERCS> `
  -ConfigurationName PrivilegedEndpoint `
  -Credential $cred `
  -SessionOption (New-PSSessionOption -Culture en-US -UICulture en-US)

# 4. 进入 PEP 会话
Enter-PSSession $pep

# 5. 获取更新状态
Get-AzureStackUpdateStatus

13.3 Get-AzureStackUpdateStatus 输出

L0 版本事实

Get-AzureStackUpdateStatus cmdlet 返回当前正在运行、已完成或失败的更新的状态。它提供：

更新操作的高级状态（InProgress / Completed / Failed）；
XML 文档描述当前步骤和相应状态------这是分步骤的状态报告，每个子步骤都有自己的状态。

13.4 PEP 与管理员门户的边界

L3 最佳实践

维度	管理员门户	PEP
典型使用	日常运维	应急排查
可观察的细节	高层级更新状态 + 子步骤摘要	同等（甚至更细，因为 XML 全文）
可触发恢复	是（"恢复"按钮）	是（`Resume-AzureStackUpdate`）
需要 Token	通常不需要	通常不需要
会话管理	无（HTTP）	PowerShell Remoting Session

14. 恢复失败的更新

L1 微软硬要求

如果更新失败，可以通过门户或 PEP 从中断的位置恢复更新 。在某些情况下，可能需要先完成缓解步骤，然后才能恢复更新。

14.1 两条恢复路径的对照

维度	管理员门户	PEP PowerShell
入口	导航到更新运行详细信息的窗格 → 点击 "恢复"	`Resume-AzureStackUpdate` cmdlet
操作	单击按钮触发恢复	从失败点恢复当前更新安装
代码示例	N/A（GUI）	见下方

14.2 PEP 恢复 PowerShell 示例

复制代码

# 1. 建立 PEP 会话
$pepSession = New-PSSession -ComputerName Azs-ERCS01 `
  -ConfigurationName PrivilegedEndpoint `
  -Credential (Get-Credential)

# 2. 在 PEP 会话中执行恢复
Invoke-Command -Session $pepSession -ScriptBlock {
  Resume-AzureStackUpdate
}

14.3 恢复前的"缓解步骤"

L3 最佳实践

在某些情况下，必须先完成缓解步骤才能恢复更新。常见的缓解步骤类型：

磁盘空间不足 ------ 清理 updateadminaccount 存储中旧版本包；
网络瞬断 ------ 检查 PEP 到 ERCS 网络可达性；
被 earlier 失败阻塞 ------ 重启被卡的服务（PEP cmdlet 由微软支持 / 故障排查团队执行）。

L1 微软硬要求 ：Resume-AzureStackUpdate 不能跳过"被标为失败的子步骤" ------它从失败点继续，但不会重跑已经成功的步骤。这保证幂等，但也意味着前面失败原因必须先解决。

15. Dell OEM P&U：硬件侧的更新工具链

L2 OEM 实现

Dell OEM 的更新与 Microsoft 更新使用不同的工具 ，但最终仍在管理员门户中体现。Dell 提供两类工具域：

15.1 Dell 管理工具的工具域

工具	内容	下载位置
Dell 修补程序和更新自动化（Dell Patch and Update Automation）	HLH 和戴尔网络交换机更新（HLH 固件、HLH / MGMTVM OS、戴尔交换机固件）	Dell 支持（按产品）页面
Dell Customer Toolkit	服务器偏移配置 / 硬件监控实时清单 / 交换机 QoS 配置等 Dell 管理软件	Dell Customer Toolkit 和 Dell 支持按产品页面

15.2 两类工具的工程边界

L3 最佳实践

Dell Patch and Update Automation （DPUA）------ 它处理硬件层的更新：节点 firmware、HLH OS、MGMTVM OS、Secure Connect Gateway 设备软件、交换机固件；
Dell Customer Toolkit ------ 它处理配置层的更新：QoS、硬件监控清单、服务器偏移配置等；
两者不重叠------DPUA 不动配置，DCT 不动固件 / 驱动。

16. Dell Patch & Update Automation 工作流

L2 Dell 实现

Dell Patch & Update Automation 有两个工作流程。

16.1 两个工作流的关系

复制代码

[工作流 1: 预检查]
  ├─ 扫描系统组件
  ├─ 与已下载的 Dell Customer Toolkit 对比
  ├─ 显示每个组件的可用更新（如果有）
  └─ 输出："有可用更新 / 无可用更新"

       ↓（如果"有"，则进入）

[工作流 2: 升级]
  ├─ 启动升级工作流
  ├─ 按顺序更新所有"有可用更新"的组件
  ├─ **管理员无法取消选择工作流中的任何步骤**
  ├─ 完成后展示"摘要"窗口
  └─ 输出："成功 / 部分失败"

       ↓（所有修补和升级工作流完成后）

[总结]
  └─ 应用产品版本（Product Version）

16.2 预检查工作流的细节

L2 Dell 实现

扫描对象：HLH 固件、HLH OS、MGMTVM OS、Dell-MGMTVM 上的 Secure Connect Gateway、戴尔交换机固件、Dell 服务器固件；
比对对象：Dell Customer Toolkit 中已下载的最新版本；
输出：每个组件的"当前版本 / 最新版本 / 是否需要更新"三栏视图。

16.3 升级工作流的边界

L2 Dell 实现

升级顺序固定 ------ 预检查列出的有更新组件按预定义顺序 升级，管理员无法干预；
不可跳过 ------ 即使管理员临时想跳过某个组件的更新，工具不接受这种操作；
原子化视图 ------ 升级过程全程只展示"摘要"，不暴露每个子步骤详情。

L3 最佳实践 ：升级工作流的不可干预特性既是优点也是风险 ------管理员在启动前应在预检查阶段多次确认，避免启动后无法中断。

17. 分析更新日志

L0 版本事实

Azure Stack Hub 允许下载每次更新运行的所有成功和失败更新的日志文件。

17.1 日志类型与解析

L0 版本事实

日志文件本身是一个 JSON 文件。要使其更具可读性，使用 PowerShell 解析：

复制代码

$json = Get-Content C:\Updatelogs_4848628f-0f78-4b3f-9258-50728254a202.json `
  | ConvertFrom-Json

# Get top-level steps
$json.properties.progress.steps.steps

17.2 日志字段解读

L0 版本事实

复制代码

name          : PreUpdate Cloud
description   : Copy packages to NugetStore.
errorMessage  :                                 # ← 关键字段，有内容则说明此步有错
status        : Success                         # ← Success / Failed / InProgress
startTimeUtc  : 2018-01-04T06:30:32.471Z
endTimeUtc    : 2018-01-04T06:43:20.758Z
steps         : {}                              # ← 子步骤

17.3 日志分层视图

L3 最佳实践

实际生产里，更新日志的"层" 至少分四层：

层	内容	何时需要
L1 元数据	更新包本身的信息（时间、版本、组件）	日常审计
L2 子步骤 XML/JSON	更新运行的步骤树（如上方示例）	失败诊断
L3 错误码 / 详细报错	每个失败步骤的错误码、堆栈	深度诊断 / 联系 Support 时必带
L4 全栈日志	一体机所有组件的日志（Get-AzureStackLog）	跨组件问题 / 长期排查

L3 最佳实践 ：分析失败时至少收集 L1 + L2 + L3 。给 Support 团队提 case 时，L4 才是关键 ------但上传带宽很大，应在确实跨组件问题时才收集。

18. 其他日志：Get-AzureStackLog

L1 微软硬要求

若要收集其他日志（跨组件）、可以使用门户或 PEP 中的 Get-AzureStackLog。

18.1 PEP 收集的标准示例

复制代码

# 1. 建立 PEP 会话
$pepSession = New-PSSession -ComputerName Azs-ERCS01 `
  -ConfigurationName PrivilegedEndpoint `
  -Credential (Get-Credential)

# 2. 在 PEP 会话中执行 Get-AzureStackLog
Invoke-Command -Session $pepSession -ScriptBlock {
  Get-AzureStackLog -OutputDir \\accessible\path
}

L0 版本事实

上面的示例将收集所有与 Azure Stack Hub 相关的日志文件，并将其写入网络共享路径。

18.2 与专门日志的边界

L3 最佳实践

维度	更新日志（§17）	Get-AzureStackLog（§18）
聚焦对象	单次更新运行	一体机全栈（NRP / NC / SLB / Gateway / HRP / Storage ...）
触发时机	更新完成后下载	一体机出现跨组件问题时
典型大小	几 MB 到几十 MB	几 GB 到几十 GB
使用对象	客户管理员	主要给微软 / OEM Support（很少客户自己看）

L1 微软硬要求 ：Get-AzureStackLog 是 Microsoft 内部 / OEM 运维 cmdlet ------ 客户运维不经常直接调用，通常由 Support 团队远程触发。

19. 四个常见误判信号

管理员初次接触更新流程时容易误判。下面补充四条 L3 最佳实践层面的常见误判补足：

19.1 上传更新包到 updateadminaccount ≠ 自动安装

不少新管理员会以为"上传包 = 自动安装"。实际上上传只是把包放到存储，仍需要在"更新"磁贴点击"立即更新"。管理员看到包出现在更新磁贴上才说明上传成功。

19.2 安装时报"包无效" ≠ 应换包

"包无效"通常意味着 MinVersionRequired 不匹配 或 包文件损坏 ------但不一定是包本身问题 。管理员应先检查当前一体机版本是否 ≥ MinVersionRequired。

19.3 恢复失败 ≠ 包本身有问题

恢复失败的常见原因是底层问题没有先被缓解 （如磁盘满、网络断、证书过期）。管理员不应立即怀疑包本身，而是先按 PEP 输出诊断底层状态。

19.4 Update Run 卡在某步 ≠ 系统严重故障

Update Run 在某个步骤停留长时间（特别是 PreUpdate / Update SeedRing 等环节）可能是正常的资源调度节奏 ------管理员应在至少观察 1 小时之后才判定为"卡住"。

20. 四条更新场景红线

L3 最佳实践 + L1 微软硬要求

更新场景的"绝对不能这么做的"红线：

20.1 红线 1：不得使用 offline update URL 越过微软后台

Offline Update Downloader 工具的目的是支持气隙 / 弱网环境 ，而不是为了避开微软的版本管理。所有更新仍要走 Microsoft / OEM 官方通道（aka.ms/azurestackupdatedownload / aka.ms/azurestackupdate），不应使用非官方 URL。

20.2 红线 2：不得在升级期间关闭 adminportal

adminportal 是 HRP 的可视化入口。关闭 adminportal 不能停止升级进程 ------升级由 ERCS 控制面管理；停止 adminportal 仅让管理员"看不到进度"，升级进程仍在跑 ，但管理员失去观测手段。

20.3 红线 3：不得手工覆盖 S2D 在升级窗口内的状态

升级期间 S2D 可能处于 degraded 状态（节点重启、rebalance 等）。手工覆盖 S2D 会破坏升级的预期恢复路径。

20.4 红线 4：不得擅自降级到比 MinVersionRequired 低的版本

降级操作不被支持 ------一旦降级，可能失去微软 / OEM Support ，且不能保证数据完整性 。如果一体机版本过老、走不到新版本，必须按 N-2 顺序逐版本升级。

21. 下篇小结：补丁与更新的工程化整合

本文围绕 PPT 中"补丁与更新"章节（slide 20-46），展开了 Azure Stack Hub 补丁与更新的全流程：

§1-2 阐述更新全流程图与服务策略（N-2 窗口）；
§3-8 拆解 Microsoft 更新与 Dell OEM 扩展包、Microsoft 更新类型、版本命名规范、metadata、更新顺序；
§9-14 展开下载 → 上传 → 安装 → 监控 → 恢复的标准流程；
§15-16 阐述 Dell P&U Automation 工作流；
§17-18 给出日志分析与 Get-AzureStackLog 的双层方法；
§19-20 补充四条常见误判信号与四条更新场景红线。

三篇系列收束 ：本文是 监控与更新三篇系列 的第 3 篇。本系列三篇按"告警机制 → ITSM 集成 → 补丁与更新"完整呈现 Azure Stack Hub 一体机的运维主线：

上篇《监控理念与告警机制》------ 告警是怎么生成的、谁负责调度、HRP 的中央角色；

中篇《监控与集成》------ 告警如何流入 SCOM / Nagios / ITSM 等企业栈；

下篇（本文） 《补丁与更新》------ 告警如何通过更新流程收敛------这是告警的最终修复路径。

参考与延伸阅读：

微软 Azure Stack Hub 服务策略：https://docs.microsoft.com/en-us/azure/azure-stack/azure-stack-servicing-policy
微软 Azure Stack Hub 更新文档：http://aka.ms/azurestackupdate
微软 Azure Stack Hub 更新下载程序（离线版）：https://aka.ms/azurestackupdatedownload
微软 AzureStack-Tools - Infrastructure：https://github.com/Azure/AzureStack-Tools/tree/master/Infrastructure
Azure Stack Hub Operator 文档（当期 azs 版本为准）
当期 OEM Support Matrix（Dell Patch & Update Automation / Dell Customer Toolkit 等）

Azure Stack Hub 补丁与更新：从服务策略到日志分析（下篇）

修订说明：

目录

1. Azure Stack Hub 更新的全流程图

1.1 完整流程图

2. 服务策略与版本支持窗口

2.1 核心策略原则

2.2 落后三个版本以上的实际后果

3. Microsoft 更新 vs Dell OEM 扩展包

3.1 两种更新包的对照

3.2 Dell 提供的两类补丁

4. Microsoft 软件更新类型

4.1 Microsoft 发布节奏

4.2 三种类型的工程含义

5. 更新包版本控制与命名规范

5.1 命名规范

5.2 命名规则的解读

5.3 命名约定的工程含义

6. 更新包文件结构与 metadata.xml

6.1 三类文件说明

6.2 metadata.xml 的关键字段

6.3 metadata.xml 是审计源

7. 更新研发与发布流程

7.1 研发流程

7.2 多节点验证

8. 更新顺序规则

8.1 三条核心规则

8.2 顺序安装的工程含义

8.3 Dell 端的对应流程

9. 下载更新包：在线 vs 离线

9.1 在线（默认）

9.2 离线 / 带外

10. 上传更新包：管理员门户的 6 步流程

10.1 上传流程表

10.2 上传后的可见性

11. 开始更新：管理员门户操作

11.1 标准操作流程

11.2 关键观察点

12. 开始更新：PowerShell 操作

12.1 四个核心 cmdlet 速查

12.2 安装示例

13. 查看更新进度：PEP 与管理员门户

13.1 两套查看路径

13.2 PEP 会话建立的标准步骤

13.3 Get-AzureStackUpdateStatus 输出

13.4 PEP 与管理员门户的边界

14. 恢复失败的更新

14.1 两条恢复路径的对照

14.2 PEP 恢复 PowerShell 示例

14.3 恢复前的"缓解步骤"

15. Dell OEM P&U：硬件侧的更新工具链

15.1 Dell 管理工具的工具域

15.2 两类工具的工程边界

16. Dell Patch & Update Automation 工作流

16.1 两个工作流的关系

16.2 预检查工作流的细节

16.3 升级工作流的边界

17. 分析更新日志

17.1 日志类型与解析

17.2 日志字段解读

17.3 日志分层视图

18. 其他日志：Get-AzureStackLog

18.1 PEP 收集的标准示例

18.2 与专门日志的边界

19. 四个常见误判信号

19.1 上传更新包到 updateadminaccount ≠ 自动安装

19.2 安装时报"包无效" ≠ 应换包

19.3 恢复失败 ≠ 包本身有问题

19.4 Update Run 卡在某步 ≠ 系统严重故障

20. 四条更新场景红线

20.1 红线 1：不得使用 offline update URL 越过微软后台

20.2 红线 2：不得在升级期间关闭 adminportal

20.3 红线 3：不得手工覆盖 S2D 在升级窗口内的状态

20.4 红线 4：不得擅自降级到比 MinVersionRequired 低的版本

21. 下篇小结：补丁与更新的工程化整合