Azure Stack Hub 管理员日常操作：从 StampInformation 到 PEP、区域管理与容量监管

未经同意，请勿转载！

本文聚焦管理员在 Azure Stack Hub 上执行的"日常操作全景" ------ 从部署完成时收到的 AzureStackStampInformation.json 入口文件，到管理员门户、特权终结点（PEP）、区域管理、容量监管，构成完整的管理员操作蓝图。

系列预告 ：本篇为 三篇运维实战系列 的第 1 篇（管理员篇）：

第 1 篇（本文）：管理员日常操作 ------ StampInformation、管理员门户、特权终结点（PEP）、区域管理、容量监管。

第 2 篇（租户篇）：用户操作 ------ 订阅创建、虚拟网络、NSG、VM、VMSS、VM 监控、ARM 模板部署。

第 3 篇（报修篇）：报修与技术支持 ------ Dell + Microsoft 双供应商协同支持流程、SLA 升级路径、紧急联系方式。

版本基础 ：本文基于 azs-2005 至当前主流 azs 版本 （覆盖 azs-2002 / 2005 / 2102 / 2206 / 2301 / 2405 / 2503 等）的 Azure Stack Hub Operator 文档整理。不同 OEM 集成系统以及不同 azs 版本之间可能存在差异 ，当版本与本文表述不一致时，以当期版本 Azure Stack Hub Operator 文档 + 当期 OEM Support Matrix 为准。

修订说明：

本篇为 Azure Stack Hub 运维管理三篇系列 · 管理员篇首发版，基于作者的内训材料《Azure Stack Hub 运维管理》整理，按四层原则做工程化改写。

[管理员操作全景：从 StampInformation 到容量监管](#管理员操作全景：从 StampInformation 到容量监管)
[StampInformation.json：管理员拿到 Azure Stack Hub 的"第一张地图"](#StampInformation.json：管理员拿到 Azure Stack Hub 的"第一张地图")
[两个门户：用户门户 vs 管理员门户的边界](#两个门户：用户门户 vs 管理员门户的边界)
管理员门户：日常操作的"主入口"
[特权终结点 PEP：受限的 PowerShell 应急工具](#特权终结点 PEP：受限的 PowerShell 应急工具)
[获取 PEP IP 地址：管理员门户中的标准流程](#获取 PEP IP 地址：管理员门户中的标准流程)
[PEP 三节点分布：ERCS01/02/03 的 HA 拓扑](#PEP 三节点分布：ERCS01/02/03 的 HA 拓扑)
[从 HLH / OAW 访问 PEP：可信主机配置](#从 HLH / OAW 访问 PEP：可信主机配置)
[建立 PEP 会话：PowerShell Just Enough Administration](#建立 PEP 会话：PowerShell Just Enough Administration)
[PEP 的常见误用：三个不该这么做的操作](#PEP 的常见误用：三个不该这么做的操作)
[区域管理：管理员操作 Azure Stack Hub 的资源单位](#区域管理：管理员操作 Azure Stack Hub 的资源单位)
容量管理界面：管理员门户的容量选项卡
四层原则落地：管理员操作的全景分层
三大误判信号：管理员日常最容易踩的坑
四条操作红线：管理员绝对不能越的边界
上篇小结：管理员操作的工程化整合

1. 管理员操作全景：从 StampInformation 到容量监管

Azure Stack Hub 管理员（Operator）在日常运维中需要执行的绝大多数操作集中在以下五类入口：

复制代码

                Azure Stack Hub 管理员日常操作
                          │
        ┌─────────────────┼─────────────────────┐
        │                 │                     │
   入口文件             PowerShell 入口          管理员门户入口
   (StampInformation)  (PEP/CloudAdmin)        (adminportal)
        │                 │                     │
   ┌────┴────┐       ┌────┴─────┐         ┌─────┴──────┐
   │         │       │          │         │            │
 部署后  后续   PEP (受限)   Operator    区域管理    容量
 摘要    维护   PowerShell  PowerShell   磁贴        选项卡

核心入口特性对比：

入口类型	作用对象	适用场景	权限范围	典型操作
StampInformation.json	静态文本文件	部署后寻址	仅阅读	拿到门户 URL / 终结点列表
管理员门户	图形化 Web UI	日常运维 ≥ 90% 操作	全局管理员（CloudAdmin 等价）	创建 plan / offer / 订阅、监视、容量
PEP	受限 PowerShell	不常见 / 紧急操作	JEA 受限 cmdlet 集	收集日志、查看健康状态
Operator PowerShell	完整 PowerShell	自动化 / 脚本	全局管理员	创建资源、配额、计费
HLH / OAW 强化 VM	RDP / SSH 跳板	接入 PEP 前的准备	本地管理员	添加可信主机、采集遥测

L3 最佳实践 ：对管理员日常操作 而言，建议优先级顺序 为 管理员门户 → Operator PowerShell → PEP。PEP 应该被视为"应急工具"而非"日常工具"------它有审计成本、生产时段修改风险、HA 节点故障风险。

2. StampInformation.json：管理员拿到 Azure Stack Hub 的"第一张地图"

2.1 文件本质

AzureStackStampInformation.json 是 Azure Stack Hub 在部署结束时自动生成的一份 JSON 摘要文件，由 OEM 集成系统（Lenovo / Dell / HPE 等）在客户签收前交付给客户。其核心特征：

包含在 Azure Stack Hub 部署后移交给客户时的一份预生成摘要。
在每个 Azure Stack Hub 部署结束时自动创建------不是运维中持续更新的文件。
包含 Azure Stack Hub 环境的部署后摘要------一次性静态快照。
包含环境的所有终结点地址 ，包括租户门户 和管理员门户。

2.2 内容结构

AzureStackStampInformation.json 通常包含以下字段（以文档示意格式说明）：

字段分类	内容	用途
外部域信息	区域名 + 外部 FQDN	拼出门户 URL
门户 URL	管理员门户（adminportal）+ 用户门户（portal）	登录入口
服务终结点	Azure Resource Manager / Key Vault / Graph 等	自动化脚本入口
基础设施 URL	BLOB / Table / Queue endpoint	存储脚本
基础设施版本	azs 版本号 + OEM 型号	OEM 兼容性核对

重要：如果 AzureStackStampInformation.json 不可用，门户 URL 可以基于 Azure Stack Hub 部署的区域名称 + 外部完全限定域名（FQDN） 的组合拼接出来。两种典型命名格式：

复制代码

管理员门户：https://adminportal.<region>.<FQDN>
用户门户  ：https://portal.<region>.<FQDN>

其中：

<region>：Azure Stack Hub 部署时指定的区域名（如 local / azurestack 等，由运营商决定）。
<FQDN>：外部完全限定域名（部署时配置，因 OEM / 客户而异）。

2.3 拿到文件后的"第一件事"

管理员拿到 Azure Stack Hub 后的标准动作清单（L3 最佳实践）：

备份 AzureStackStampInformation.json------这是后续所有"门户地址寻址"的快速入口；任何脚本开发、自动化 Runbook、监控平台对接都需要从这里读取。
核对终结点------用浏览器或 PowerShell 验证管理员门户可达，避免后续操作因基础寻址错误而拖慢。
建立权限矩阵 ------记录 CloudAdmin / DnsAdmins / 各种特权终结点账户的密码策略、保管位置、轮换计划。

2.4 常见误判信号

L3 最佳实践·从经验提取：以下三种"看起来异常但不是故障"的情况在首次部署后很常见：

StampInformation 中只列了几个终结点 ------ 这是正常的，因为部分终结点（如 *.admin.<FQDN>）会随首次注册 Azure 之后才出现。

JSON 中的端口 / 路径不是"标准 Azure"格式 ------ 这取决于 OEM 客户的网络规划。

文件存放在 HLH（Hardware Lifecycle Host）的特定路径 ------ 这是 OEM 部署约定，部分 OEM 会放在 HLH 而非 ERCS VM。

3. 两个门户：用户门户 vs 管理员门户的边界

Azure Stack Hub 部署后，运营商可用的两个独立门户承担完全不同的责任：

3.1 门户的本质差异

维度	用户门户（Tenant Portal）	管理员门户（Admin Portal）
访问 URL	`https://portal.<region>.<FQDN>`	`https://adminportal.<region>.<FQDN>`
登录凭据	AAD 用户 / ADFS 用户（租户视角）	云管理员账户（CloudAdmin 或等价）
可视资源	该用户有权访问的订阅、资源、资源组	Azure Stack Hub 基础设施资源、租户订阅、容量
可执行操作	创建 / 管理自己订阅内的资源	创建 plan / offer / 订阅、监视基础设施健康、下载市场项目等
权限模型	RBAC（Subscription / Resource Group 范围）	CloudAdmin 全局管理员

3.2 管理员门户的关键能力

在管理员门户中，管理员可执行以下动作（PPT slide 5 原文）：

监视运行状况和警报。
管理 Azure Stack Hub 更新。
为用户创建计划、优惠和订阅。
下载市场项目。

3.3 管理员门户 URL 的构成

L1 微软硬要求 ：管理员门户 URL 因 Azure Stack Hub 部署的区域名称和**外部完全限定域名（FQDN）**而异。具体格式：
复制代码
https://adminportal.<region>.<FQDN>
其中 <region> 和 <FQDN> 在部署时由客户 / OEM 配置。这是一个事实陈述，不是设计选择。

3.4 典型访问流程

Web 浏览器输入管理员门户 URL（优先用 Edge / Chrome，IE 不支持）。
凭据登录------使用 CloudAdmin 等价管理员账户（域账户 AzureStack\CloudAdmin 或 AAD 同步账户）。
默认仪表板显示基础设施运行状况摘要。
左侧导航进入"区域管理"、"市场"、"计划"等模块。

L3 最佳实践 ：登录后建议第一件事是访问"区域管理 → 属性"，确认外部域信息、PEP IP、Capacity 当前值；这些是脚本调用的基础。

4. 管理员门户：日常操作的"主入口"

4.1 日常操作覆盖面

原文：对于 Azure Stack Hub 管理员，大多数日常操作都是通过管理门户或 PowerShell 完成的。对于某些不常见的操作，可以使用特权终结点（PEP）。

这句话揭示了一个经验事实 ：操作频度分布是严重偏斜的------90% 以上的日常运维都集中在管理员门户。具体分类：

操作类别	入口	频度
监视运行状况 / 警报	管理员门户 → 仪表板	高（每小时 / 每天）
创建 plan / offer / 订阅	管理员门户 → 计划	中（按周）
管理更新	管理员门户 → 更新	中（按月）
下载市场项目	管理员门户 → 市场管理	中（按周）
用户管理	AAD / ADFS	持续
资源配额调整	Operator PowerShell	中（按周）
故障排除	PEP + 日志	低（按需）

4.2 核心磁贴清单

管理员门户首页的几个核心磁贴（取决于 azs 版本可能略有差异）：

磁贴	作用	L1/L2 分类
区域管理	整个 Stamp 的运行状态 / 容量 / 更新	L1 微软硬要求
市场	Marketplace 项目管理	L1 微软硬要求
计划	创建 plan / offer	L1 微软硬要求
资源提供程序	注册 Azure 资源管理器 RP（如 `Microsoft.Compute`）	L2 OEM 实现差异
监视	警报 / 运行状况	L1 微软硬要求
警报	当前未确认的报警	L1 微软硬要求
容量	订阅数 / VM 部署数 / 资源用量	L1 微软硬要求
更新	Update Bundle 上传 / 安装	L1 微软硬要求
属性	部署摘要 + PEP IP	L1 微软硬要求

L1 微软硬要求 ：上面表格中"区域管理 / 市场 / 计划 / 监视 / 更新"等是微软在所有 azs 版本都提供的固定入口，而"资源提供程序 / 容量"的入口呈现方式取决于 azs 版本 + 个别 OEM 客户定制。

5. 特权终结点 PEP：受限的 PowerShell 应急工具

5.1 是什么

特权终结点（PEP）是一个远程 PowerShell 控制台，它为您提供了 PowerShell Just Enough Administration（JEA），提供一组受限制的 cmdlet 命令。

PEP 是 Azure Stack Hub 提供的一个远程 PowerShell 控制台 ，但是不是"完整管理员权限" ------它通过 PowerShell 的 Just Enough Administration（JEA）能力只暴露一组受限制的 cmdlet 命令。

PEP 的 cmdlet 通常包含：

状态查询 ：Get-AzureStackStampInformation、Get-AzureStackLog、Get-AzureStackDiagnosticData 等
基础诊断 ：Test-AzureStack、Repair-Volume 等
收集日志 ：Get-AzureStackLog -FilterByRole XYZ
备份 / 还原动作（部分 cmdlet，需要谨慎使用）
修补 / 更新相关：需要通过 PEP 触发并由 OEM 监督

L1 微软硬要求 ：Get-AzureStackLog 这种诊断日志收集 cmdlet 只通过 PEP 暴露，不在 Operator PowerShell 中提供。这是微软故意设计的"应急工具"定位。

5.2 适用场景

原文：使用 cmdlet 可以检查 Azure Stack Hub 的状态和运行状况，并收集诊断日志。

PEP 的核心使用场景：

收集诊断日志 ------ Get-AzureStackLog 是最有用的 cmdlet，自动收集全部基础设施角色日志
状态检查 ------ Test-AzureStack 系列 cmdlet 验证 Patch / Update / Service Health
应急操作 ------ 当管理员门户 / Operator PowerShell 都不工作时，PEP 是最后的"逃生舱"

L3 最佳实践 ：日常运维不要优先使用 PEP ------因为 PEP 的所有操作都会被深度审计，对 Scale Unit 节点有 root 级影响，且部分 cmdlet 在生产时段执行会触发自动恢复。建议只在微软 / OEM 指导后使用。

5.3 不能用 PEP 做的事

操作	是否 PEP 内可用	替代入口
创建资源 / 订阅	❌	管理员门户 / Operator PowerShell
修改 tenant 配置	❌	管理员门户 / Operator PowerShell
修改 OEM 网络配置	❌ 也不应该	OEM Support
重启 ERCS VM	⚠️ 谨慎	通常应通过 PEP 触发且仅维护时段
安装 Update Bundle	⚠️ 谨慎	管理员门户 → 更新

6. 获取 PEP IP 地址：管理员门户中的标准流程

6.1 标准操作步骤

原文（精简重写）：

使用 Web 浏览器登录到 Azure Stack Hub 管理门户，单击"区域管理"磁贴，然后单击"属性"。

在"属性"窗格中，若要查看 IP 地址，请转到"特权终结点 IP 地址"。

实际在管理员门户中：

打开浏览器，访问 https://adminportal.<region>.<FQDN>。
使用 CloudAdmin 等价账户登录。
在左侧导航或默认仪表板中单击 "区域管理" 磁贴。
在"区域管理"边栏中，单击顶部 "属性" 选项卡。
滚动到 "特权终结点 IP 地址" 部分------这里会列出 PEP 虚拟机（AzS-ERCS01 / 02 / 03）对应的内部 IP。

L3 最佳实践 ：PEP IP 通常是内部 IP（Scale Unit 内的 192.168 或 10.x 私网地址段），不是公网地址。访问 PEP 必须经过 HLH（Hardware Lifecycle Host）或强化 VM 在同一私网中。

6.2 何时会用到 PEP IP

场景	用法
首次建立 PEP 会话	添加为可信主机 + 远程 PowerShell 进入
自动化日志收集	用 IP 作为 `Enter-PSSession -ComputerName` 参数
多 PEP 实例 HA	按需选择不同 ERCS 实例（01/02/03）

7. PEP 三节点分布：ERCS01/02/03 的 HA 拓扑

7.1 三个 ERCS VM

PEPP 虚拟机有多个实例，每个实例都在单独的缩放单元节点上运行，以实现高可用。

Azure Stack Hub 部署时会自动创建三个 ERCS（Emergency Recovery Console Service）虚拟机，它们具有固定命名约定：

虚拟机名	部署位置	HA 角色
`AzS-ERCS01`	Scale Unit 内某物理节点	主动 / 候选
`AzS-ERCS02`	Scale Unit 内另一物理节点	主动 / 候选
`AzS-ERCS03`	Scale Unit 内第三物理节点	主动 / 候选

L2 OEM 实现 ：ERCS VM 不是微软"软虚拟化"的标准 VM；它运行的是独立、轻量、补丁隔离的 OS 镜像 ，目的是提供一个对节点硬件故障具备弹性的应急访问入口。

7.2 拓扑示意

复制代码

            Azure Stack Hub Scale Unit (4-16 节点)
        ┌─────────────────────────────────────────┐
        │                                         │
        │   ┌──────────┐    ┌──────────┐    ┌──────────┐   │
        │   │  Node 1  │    │  Node 2  │    │  Node 3  │   │
        │   │          │    │          │    │          │   │
        │   │ [AzS-    │    │ [AzS-    │    │ [AzS-    │   │
        │   │  ERCS01] │    │  ERCS02] │    │  ERCS03] │   │
        │   │          │    │          │    │          │   │
        │   └─────┬────┘    └─────┬────┘    └─────┬────┘   │
        │         │              │              │          │
        └─────────┼──────────────┼──────────────┼──────────┘
                  │              │              │
                  ▼              ▼              ▼
                VIP (PEP IP)        ------ 对外表现单一终结点

L1 微软硬要求 ：PEP 至少有 3 个 ERCS VM 实例；这是设计上的"三节点 HA"基线 ------ PEP 不能因为某台物理节点故障而失联。当操作员登录 PEP 时，可能随机连接到三个节点之一。

7.3 三个 ERCS VM 的可见性

Azure Stack Hub 环境中，虚拟机被命名为 AzS-ERCS01, AzS-ERCS02, 和 AzS-ERCS03。

ERCS VM 不在管理员门户的"虚拟机"列表中可见------它们属于基础设施对象，仅在管理员门户的"区域管理" → "属性"中以 IP 形式出现。在 Hyper-V Manager / Failover Cluster Manager 中也看不到它们（出于安全隔离）。

L3 最佳实践：日常运维不要尝试"找出 ERCS VM 在哪个节点"------它是已封装的 HA 入口。

8. 从 HLH / OAW 访问 PEP：可信主机配置

8.1 HLH / OAW 是什么

组件	全称	作用	部署位置
HLH	Hardware Lifecycle Host	OEM 提供的硬件生命周期管理机	Scale Unit 物理机（客户机房）
OAW	Operator Access Workstation	操作员访问工作站	客户额外准备的强化 VM

L3 最佳实践：微软强烈推荐使用 OAW 作为日常"管理员工作站"------它是加固过的、不加入域、只能远程到 PEP 的特殊 VM。

8.2 添加可信主机

在集成系统上，从提升的 Windows PowerShell 会话运行以下命令，将 PEP 添加为 HLH 或特权访问工作站（OAW）上运行的安全强化 VM 上的受信任主机：
复制代码
winrm s winrm/config/client '@{TrustedHosts="IP Address of Privileged Endpoint"}'

这段命令的关键细节：

必须在提升的 PowerShell 中运行 ------ 因为修改 WinRM 受信任主机需要管理员权限。
只能在 HLH 或 OAW 上执行 ------ 不能在任意工作站执行；PEP 设计上只接受来自这些可信强化 VM 的连接。
TrustedHosts 接收 PEP IP 字符串 ------ 这正是第 6 节取到的 PEP IP。

L1 微软硬要求 ：在集成系统（OEM 集成系统上的客户环境）上，PEP 默认只接受来自 HLH / OAW 的可信主机 ------直接在客户日常办公工作站上是无法连接 PEP 的。这是设计上的"封闭信任域"原则。

8.3 可信主机的工程解读

winrm s winrm/config/client '@{...}' 命令的本质是把 PEP IP 写入当前 WinRM 客户端的"受信任主机"列表。

WinRM 受信任主机的作用：当 WinRM 客户端连接一个不在 Active Directory 信任域内的目标时，WinRM 默认拒绝；只有"受信任主机"列表中的 IP / DNS 名才允许连接。

避免误解 ：TrustedHosts 不等于 网络可达性。TrustedHosts 是身份验证层 的设置（解决"非 AD 域机器也能建立 WinRM 会话"），与网络 ACL / 防火墙 / IP 路由是不同的关注点。

因此，访问 PEP 需要三层条件同时满足：

网络层：PEP 私网 IP 与 HLH / OAW 在同一私网段，可路由可达。

身份验证层 ：TrustedHosts 包含 PEP IP。

凭据层 ：CloudAdmin 凭据（域账户 Azure Stack Hub 域\cloudadmin）。

9. 建立 PEP 会话：PowerShell Just Enough Administration

9.1 标准命令

在 HLH 或特权访问工作站（OAW）上运行的强化 VM 上，打开 Windows PowerShell 会话。运行以下命令，在托管 PEP 的 VM 上建立远程会话：
复制代码
$cred = Get-Credential
Enter-PSSession -ComputerName azs-ercs01 -ConfigurationName PrivilegedEndpoint -Credential $cred

注意几个关键参数：

-ComputerName ：可以是 PEP IP，也可以是 ERCS VM 名（azs-ercs01 等）------ PEP 会有逻辑 VIP 自动路由到健康实例。
-ConfigurationName PrivilegedEndpoint ：JEA 配置名，这是 PEP 与普通 PowerShell Remoting 的唯一区别。
-Credential ：用 Get-Credential 弹出交互式对话框输入凭据。

9.2 凭据格式

用户名 ：指定 CloudAdmin 帐户，格式为 <Azure Stack Hub 域>\cloudadmin。

密码：输入在安装过程中为 AzureStackAdmin 域管理员帐户提供的相同密码。

字段	值	来源
用户名	`<AzureStack 域>\cloudadmin`（例如 `AzureStack\cloudadmin`）	部署时建好的全局管理员账户
密码	与 `AzureStackAdmin` 域管理员账户相同	同上

L1 微软硬要求 ：PEP 必须使用 CloudAdmin 账户------不接受 AAD 用户 / 普通租户用户 / 任何 Operator 门户账户。这是设计上的"专用安全通道"。

9.3 连接成功提示

连接后，提示符将更改为 [IP 地址或 ERCS VM 名称]:PS> 或 [azs-ercs01]:PS>，具体取决于环境。在此处运行 Get-Command 以查看可用 cmdlet 的列表。

连接的视觉标志是 PowerShell 提示符前缀从普通主机名变为 PEP 标识，例如：

复制代码

[azs-ercs01]: PS> Get-Command

或：

复制代码

[10.0.0.10]: PS> Get-Command

L1 微软硬要求 ：在 PEP 内部，Get-Command 列出的 cmdlet 只有 PEP 暴露的受限集，不包含完整 PowerShell 模块------这是 JEA 的核心约束。

9.4 cmdlet 参考

可以在以下位置找到 cmdlet 的参考：https://docs.microsoft.com/en-us/azure-stack/reference/pep-2002/?view=azs-2005。

cmdlet 参考位置随 azs 版本变化------应以当期 azs 版本对应的"PEP 参考"文档为准 。pep-2002 等数字是 azs 版本号（如 azs-2002 → 文档 view=azs-2005）；实际可访问的文档 URL 链接可能随 microsoft docs 演进而变化。

9.5 推荐的工作流

复制代码

# 第 1 步：在 OAW 上一次性配置 TrustedHosts
Set-WSManInstance -ResourceURI "winrm/config/client" `
    -ValueSet @{ TrustedHosts = "<PEP_IP>" } `
    -Verbose

# 第 2 步：获取凭据并进入 PEP 会话
$cred = Get-Credential -UserName "AzureStack\cloudadmin" -Message "PEP CloudAdmin"
Enter-PSSession -ComputerName "<PEP_IP_or_ERCS_Name>" `
    -ConfigurationName PrivilegedEndpoint `
    -Credential $cred

# 第 3 步：进入 PEP 后最常见的操作
Get-AzureStackStampInformation
Test-AzureStack
Get-AzureStackLog -OutputPath "\\HLH\Logs\$(Get-Date -Format 'yyyyMMdd')" `
                  -FilterByRole "*,*"

9.6 PEP 的 Token 授权机制（高级用法）

当 CloudAdmin 凭据只能登入"普通 PEP"但还不够做某些 cmdlet 时，PEP 设计上提供了一条**"Token 授权升级"路径**。

9.6.1 为什么需要 Token

PEP 内有一类 cmdlet 比"只读查询"权限更高------例如 Repair-Volume / Restart-Computer / 部分 Update 相关 cmdlet。这些 cmdlet 在设计上拒绝默认 CloudAdmin 凭据 直接执行，必须经过微软售后 / OEM 工程师提升权限。

提升权限的机制是 PEP 授权 Token ------一个由微软售后技术团队 （CSS / Partner Support / FTE / Microsoft IPS / Microsoft AzS Engineering）生成的有时间窗口的字符串。

9.6.2 Token 的工程性质

维度	特征
生成方	微软售后技术团队（CSS / IPS / AzS Engineering）
携带信息	推断为"目标 Stamp ID + 期限 + 授权动作白名单"
有效期	几个小时（具体值随当期版本 / 团队策略变化）
使用方式	在 PEP 会话中通过 `Enter-PrivilegedEndpoint -Token <token>` 类 cmdlet 提交（具体语法以当期 azs 版本 cmdlet 文档为准）
审计	Token 提交会被 PEP 写到内部审计日志------PEP 接受 Token 那一刻等于微软工程师"远程背书"
撤销	Token 一旦过期或被使用，不能"补发"------需要微软售后重新生成

9.6.3 实际工作流

复制代码

Microsoft Support Engineer (CSS / IPS)
    │
    │ 1. 内部查询目标 Stamp ID
    │ 2. 生成有时限的授权 Token
    │ 3. 通过加密通道（电话 / 安全邮件 / 工单附件）送给客户
    │
    ▼
Azure Stack Hub Operator
    │
    │ 1. 拿到 Token 后进入 PEP 会话
    │ 2. 执行 Enter-PrivilegedEndpoint -Token <token>
    │ 3. 直到 Token 过期前，可在 PEP 内执行"高权限" cmdlet
    │
    ▼
Token 过期
    │
    ▼
高权限 cmdlet 重新被拒绝
    │
    ▼
如仍需高权限操作 → 重新联系 Microsoft Support

9.6.4 注意事项

L1 微软硬要求（基于实操经验）：

Token 不能代替 CloudAdmin 凭据------客户端仍需先以 CloudAdmin 身份进入 PEP，再在 PEP 内部提交 Token 升级。

Token 不能"绕过"PEP 自身的 JEA 限制 ------Token 只是把 JEA 暴露的 cmdlet 集合"放大"到包含高权限 cmdlet，不会"解除"PEP 之外的任何限制。

客户绝不能"自己生成 Token"------Token 必须由微软售后生成；客户若尝试伪造 / 复用会触发合规审计。

Token 传输建议走加密通道------不要通过普通邮件 / 微信发；建议走工单附件 / 电话当面读。

避免 Token 在内部"流传"------Token 应当直接给"执行 PEP 操作的人"，不要在群里贴。
L3 最佳实践 ：日常运维不要向微软索要 Token------只有在以下情况才需要：

微软 / OEM 工程师主动建议走 Token 升级（如某 cmdlet 在 CloudAdmin 凭据下被拒绝）

重大故障修复中需要高权限修复 cmdlet

Update 安装 / 回滚过程中需要特定 PEP 步骤（这是 Update Runbook 中常见的步骤）
L0 版本事实 ：上述 Token 机制的具体 cmdlet 名称 / 参数 / 语法 随 azs 版本变化------应以当期 azs 版本对应"PEP 参考"文档为准。本文给出的是"机制层面"的描述。

10. PEP 的常见误用：三个不该这么做的操作

L3 最佳实践（从经验提取，PPT 未明说）：以下操作在历史上是常见"事故来源"。

10.1 在生产时段执行 `Repair-Volume` / `Test-Volume`

PEP 内的一些 cmdlet 是修复性操作，可能会触发自动恢复。在生产时段执行可能引发：

短暂的存储卷回退，导致上层租户 VM 出现 I/O 暂停。
S2D 重建触发，影响性能一段时间。
意外的资源回收，引起部分租户工作负载异常。

建议：修复性 cmdlet 应在 OEM / 微软支持工程师指导下执行，且尽量选择维护窗口。

10.2 在 PEP 内修改网络配置 / 防火墙规则

PEP 的 cmdlet 集中不包含网络 / 防火墙配置 cmdlet------但管理员可能尝试通过 PowerShell 间接执行。这种行为违反设计：

客户不能修改 ToR 配置------这是 OEM 验证过的网络配置。
不能在 PEP 内 ping 网关 作为"网络可通性"测试------这只能证明 PEP 自身所在的子网通，不代表租户网络可达。

10.3 把 PEP 当成日常运维工具

PEP 是"应急舱"而非"日常工具"。把 PEP 用于日常管理会带来：

审计成本------PEP 操作被深度审计。
节点影响------部分 cmdlet 需要联系具体节点。
可移植性差------每次操作需要现场登录 HLH / OAW。

建议：日常运维只在以下情况使用 PEP：

微软 / OEM 支持工程师要求时

管理员门户 / Operator PowerShell 不可用

Get-AzureStackLog 类诊断日志收集

升级 / 修补前后的健康验证

11. 区域管理：管理员操作 Azure Stack Hub 的资源单位

11.1 区域是什么

PPT slide 11 原文 ：Azure Stack Hub 将逻辑实体定义为：由构成 Azure Stack Hub 基础设施的硬件资源组成的逻辑实体作为区域。

区域管理允许 Azure 管理员使用管理 Azure Stack Hub 基础设施所需的资源。

Azure Stack Hub 部署在单个区域中。

Azure Stack Hub 操作员可在管理员门户的默认仪表板上使用"区域管理"磁贴。

"区域"在 Azure Stack Hub 是特化的含义：

Azure 公有云	Azure Stack Hub
一个或多个数据中心的地理域	单个 Scale Unit 物理部署（4-16 节点）
可选用 Azure Region（eastasia / westus 等）	由 OEM 客户配置（`<region>` 通常为 `local` / `azurestack`）
区域之间是物理隔离	一个 Azure Stack Hub 实例就是一个区域，没有"区域间复制"概念

L1 微软硬要求 ：Azure Stack Hub 一个实例只对应一个区域 。这是与 Azure 公有云的"区域"概念的关键区别------没有"区域对区域复制" / "异地灾备"。灾备由运营商通过外部备份方案实现。

11.2 区域管理的资源范围

"区域管理"磁贴背后的资源范围包括：

基础设施运行状态（Update / Repair / Running 等状态机）
容量指标（订阅数 / VM 数 / 各服务的配额使用率）
更新管理（Update Bundle 上传 / 计划 / 状态）
属性（终结点、PEP IP、外部域信息）
用户角色（管理员账户在 AAD / ADFS 中的成员资格）
资源提供程序（RP 注册状态）

11.3 与管理员门户 / PEP 的关系

操作类型	入口	频度
查看区域状态	管理员门户 → 区域管理	高
修改容量配额	管理员门户 → 区域管理 → 容量 / Operator PowerShell	中
上传 Update Bundle	管理员门户 → 区域管理 → 更新	中
触发 Health Check	PEP 或 Operator PowerShell	低（按需）
修改基础结构	PEP + 微软支持	极低（几乎不在客户操作范围）

12. 容量管理界面：管理员门户的容量选项卡

12.1 进入方式

打开 Azure Stack Hub 管理门户链接，并使用管理员用户登录。浏览到"区域管理"边栏选项卡，然后打开"容量"选项卡。

实际路径是：

管理员门户首页 → 区域管理 磁贴 → 顶部菜单 → 容量选项卡

12.2 容量页通常显示什么

容量页通常包含以下几类信息（L0 版本事实，跨版本可能演进）：

信息类别	含义	典型单位	L 分类
订阅使用情况	已创建 / 配额	数量 / 百分比	L1 微软硬要求
各 RP 资源部署数	各资源提供程序的当前租户部署	数量 / 百分比	L1 微软硬要求
物理资源使用率	CPU / 内存 / 存储	百分比	L1 微软硬要求
阈值告警状态	接近上限告警	Yes / No	L1 微软硬要求

12.3 容量阈值的工程含义

Azure Stack Hub 的容量监视在多个层面都有阈值告警。具体阈值随 azs 版本演进------L0 版本事实：

阈值	含义
70%	容量达到该值时常作为警告线（视具体 OEM 和告警配置而定）
90%	达到该值时常作为关键告警
100%	满载------部署可能被阻止

L1 微软硬要求 ：容量显示在管理员门户中 ------管理员可以随时查看当前百分比，但具体的"阈值定义和告警触发机制"由微软 / OEM 提供，不是客户可配置的 （除非 OEM 提供了扩展能力）。具体含义以当期 azs 版本 + OEM Support Matrix 为准。

12.4 与 PEP 容量查询的区分

PEP 内也能查询容量（如 Get-AzureStackCapacity 类的 cmdlet），但这两个入口的语义不同：

入口	数据口径	适用场景
管理员门户 → 容量	微软官方 UI，聚合多 RP 数据	日常监视
PEP 内 cmdlet	可能更细粒度（含内部组件层级）	故障排查

L3 最佳实践：日常监视走管理员门户；故障排查走 PEP。

13. 四层原则落地：管理员操作的全景分层

将管理员日常操作按 L0 版本事实 / L1 微软硬要求 / L2 OEM 实现 / L3 最佳实践 四个层级重新梳理：

操作	层级	说明
`Get-AzureStackStampInformation` cmdlet 集合存在	L1 微软硬要求	这是设计上的固定 cmdlet
`Get-AzureStackStampInformation` 返回的字段名随版本可能变化	L0 版本事实	跨版本演进
管理员门户"容量"页面阈值（70%/90%/100%）为 L0 版本事实	L0 版本事实	OEM 通常不公开修改
ERCS VM 命名约定（`AzS-ERCS01/02/03`）	L1 微软硬要求	这是设计固定名
ERCS VM 在哪一个物理节点	L2 OEM 实现差异	由 OEM 部署约定
具体磁盘 / 网络 / 固件版本由 OEM 决定	L2 OEM 实现差异	Dell / Lenovo / HPE 各自 Support Matrix 不同
应使用 HLH / OAW 访问 PEP	L3 最佳实践	不是硬要求，是推荐
在维护窗口使用 `Repair-Volume` 等修复 cmdlet	L3 最佳实践	来自实战经验
容量阈值告警响应 SOP	L3 最佳实践	由客户 / OEM / 微软共同维护
管理员门户登录后"属性"首查 PEP IP	L3 最佳实践	来自经验

13.1 跨版本的演进风险

L0 版本事实：以下特性随 azs 版本演进而可能变化：

管理员门户磁贴的具体布局

容量页面显示的指标集合

PEP 暴露的 cmdlet 集合（新增 / 删除）

阈值数值（70%/90%/100% 是否仍是当前默认值）

14. 三大误判信号：管理员日常最容易踩的坑

L3 最佳实践（从经验提取，PPT 未明说）。以下三个误判在首次部署 / 新员工入职时最为常见。

14.1 误判 #1：PEP 无法 ping 就认为 PEP 故障

现象：在 OAW 上 ping PEP IP 不通，但 Enter-PSSession 却能成功。

原因：

PEP 私网位于私网段，不属于 OAW 默认 ICMP 允许范围。
但 WinRM 远程 PowerShell 用的是 TCP 5985/5986 端口，可能允许通过。

判断方法 ：以 Enter-PSSession 是否能进入 PEP 提示符为准。ping / traceroute 不通不代表 PEP 不可用。

14.2 误判 #2：ERCS VM 自动重启就认为"被攻击"

现象：在 HLH 上偶尔看到 ERCS01/02/03 之一重启。

原因：

微软更新流程会在 Scale Unit 内部轮转重启 ERCS VM 以保证 PEP 节点也能跟上 Patch。
这是设计行为，不是异常。

判断方法：查看对应时间窗口是否有 Update Bundle 安装记录。如果有，重启属于预期；如果没有，再走 PEP 健康检查。

14.3 误判 #3：容量显示"未注册"是首次部署常见状态

现象：管理员门户 → 容量首次打开时，部分 RP 显示"未注册"或"0"。

原因：

多个 Azure 资源提供程序（RP）需要单独注册 （如 Microsoft.Compute / Microsoft.Network / Microsoft.Storage 等）。
首次部署时部分 RP 可能显示为未注册，是预期状态。

处理方法 ：通过 Register-AzResourceProvider -ResourceProviderNamespace <Namespace> 或管理员门户的"资源提供程序"页面完成注册。

14.4 误判 #4（常见但容易被忽略）：StampInformation 文件中终结点不齐全

现象：JSON 中只有部分终结点，没看到 AAD Graph / Key Vault 等。

原因：

这是生成时间 问题------StampInformation 在部署结束 时生成，部分终结点（如 AAD 同步后端）还未生成。
完整终结点表会随使用而演进而补齐。

处理方法 ：以管理员门户 → 属性当前显示的终结点为准------那是"运行时"视图，比 StampInformation 更准确。

15. 四条操作红线：管理员绝对不能越的边界

L1 微软硬要求 + L3 最佳实践 。以下四条是 Azure Stack Hub 管理员在日常运维中绝对不能越的边界，违反会引发支持工单乃至合规问题。

15.1 红线 #1：不修改 OEM 验证过的物理 / 网络配置

配置类别	不可变项	影响
物理网络	ToR 交换机配置、Cable 拓扑、VLAN 划分	一旦修改即不属 OEM 验证范围，违反后所有硬件故障 / 配置漂移需客户自行承担
操作系统层	Scale Unit 节点 OS 镜像	PEP 设计上不应被客户直接修改
存储层	S2D 配置、Capacity Pool 大小、三镜像设置	直接影响数据冗余度
固件层	BMC / iDRAC / Switch Firmware	OEM 矩阵外的固件升级可能导致 HA 失联

L1 微软硬要求 ：上述配置不允许客户修改------任何修改都需要 OEM / 微软支持工程师联合评估。

15.2 红线 #2：不擅自重启 ERCS VM 或修改 PEP 配置

行为	后果
在 PEP 会话内对 ERCS VM 自身进行关机 / 重启	彻底切断 PEP 入口；只有物理 Console 才可能恢复
试图修改 PEP 的 JEA 配置 / 受信任主机	破坏 PEP 完整性，可能需 OEM 现场介入
在生产时段对某个 ERCS VM 执行 PEP 内 `Restart-Computer`	可能导致 PEP 长时间不可达

L1 微软硬要求 ：PEP 设计上不应被客户修改------PEP 是 OEM 现场工程师 + 微软支持工程师的工具，不是管理员的工具。

15.3 红线 #3：不在生产时段做大范围配置变更

虽然管理员门户是日常操作入口，但单次操作可能影响租户，因此：

大批量 plan / offer / 订阅变更------可能影响 tenant 资源访问；建议维护窗口执行。
删除活跃订阅------会立即回收租户资源；任何客户端都不应"在工作时间删除"。
资源配额大幅下调------已有租户的工作负载可能瞬间超额。

L3 最佳实践 ：上述操作应事先公告 / 维护窗口执行 / 与租户协调。管理员门户没有"操作反悔"机制，删除 / 调整是不可逆的（恢复需要从备份重建状态）。

15.4 红线 #4：不越过容量阈值强制部署

管理员门户在容量接近上限时通常不强制阻止操作------这是一个容易踩坑的点。

L3 最佳实践：

容量超过 70% 时应主动介入（扩容 / 优化 / 通知租户）。

容量超过 90% 时禁止新增订阅 / 大规模部署------任何 VM 部署可能随时失败。

容量达到 100% 时没有任何操作会成功------所有部署会因资源不足而失败。

15.5 配合第 3 篇的"报修"上下文

某些红线触发后（如 PEP 失联 / 硬件故障 / 容量长期超过阈值）需要走 Dell + Microsoft 双供应商协同报修------具体流程在**第 3 篇（报修篇）**展开。

16. 上篇小结：管理员操作的工程化整合

16.1 核心入口速查

入口	频度	典型操作
StampInformation.json	一次性（部署后）	拿到门户地址
管理员门户	≥ 90% 日常操作	监视 / 容量 / plan / offer / 市场 / 更新
Operator PowerShell	中频度	自动化 / 配额 / 大规模变更
PEP	低频度（应急）	`Get-AzureStackLog` / `Test-AzureStack`
HLH / OAW	入口前准备	`TrustedHosts` 配置

16.2 操作优先级建议（L3 最佳实践）

日常监视 ：管理员门户 → 仪表板 + 警报
日常变更 ：管理员门户 → 区域管理 → 容量 / 计划 / 市场
脚本自动化 ：Operator PowerShell
应急 / 日志收集 ：PEP（在 HLH / OAW 上）
重大变更 / 故障 ：OEM + 微软支持工程师（详见第 3 篇）

16.3 与其他两篇的关系

第 2 篇（租户篇）：覆盖管理员门户之外的所有租户操作------订阅创建、虚拟网络、NSG、VM、VMSS、监控、ARM 模板。这部分对管理员而言是"租户自治范围"，管理员不必直接介入，但需要了解典型形态以便指导租户。
第 3 篇（报修篇）：覆盖 Azure Stack Hub 故障发生时的报修路径------Dell + Microsoft 双供应商协同、紧急联系方式、跨厂商升级。管理员在红线触发后会用到这一篇的内容。

16.4 持续维护建议

定期备份 StampInformation.json 到客户管控的存储位置
维护内部 Runbook：把管理员门户的标准操作流程化
季度回顾 PEP cmdlet 列表变化（azs 版本升级时常变化）
容量阈值 SOP：建立 70%/90%/100% 三档响应流程
应急联系人维护：HLH / OAW / OEM / 微软支持联系人定期更新（详见第 3 篇）

附录 A：本文核心 cmdlet / 命令快速参考

类别	命令 / cmdlet	说明
可信主机	`winrm s winrm/config/client '@{TrustedHosts="<PEP_IP>"}'`	在 HLH / OAW 上执行
PEP 会话	`Enter-PSSession -ComputerName azs-ercs01 -ConfigurationName PrivilegedEndpoint -Credential $cred`	进入 PEP
PEP 退出	`Exit-PSSession`	返回原始 shell
StampInformation 查询	`Get-AzureStackStampInformation`	在 PEP 内执行
日志收集	`Get-AzureStackLog -OutputPath \\HLH\Logs`	在 PEP 内执行
健康测试	`Test-AzureStack`	在 PEP 内执行
Token 升级	`Enter-PrivilegedEndpoint -Token <token>`	在 PEP 内执行（具体语法以当期 azs 版本为准）

附录 B：本文相关资源链接参考

L0 版本事实 ：以下链接随微软 docs 演进可能变化------应以当期 azs 版本对应的"Azure Stack Hub Operator 文档" / "PEP 参考"文档为准。

Azure Stack Hub Operator 文档入口：https://learn.microsoft.com/en-us/azure-stack/operator/ （具体页面以当期微软文档树为准）
PEP cmdlet 参考（按 azs 版本划分如 pep-2002）：见当期 azs 版本文档

本文版本 ：v1.1（修订 · 2026-07-30）维护：Azure Stack Hub 运维管理三篇系列 · 管理员篇 写作依据 ：内训演示材料《Azure Stack Hub 运维管理》（管理员操作章节）整理 + 微软 Operator 文档 + 实操经验 下次修订触发：azs 重大版本升级、PEP cmdlet 集合发生可见变化、OEM Support Matrix 调整

Azure Stack Hub 管理员日常操作：从 StampInformation 到 PEP、区域管理与容量监管

修订说明：

目录

1. 管理员操作全景：从 StampInformation 到容量监管

2. StampInformation.json：管理员拿到 Azure Stack Hub 的"第一张地图"

2.1 文件本质

2.2 内容结构

2.3 拿到文件后的"第一件事"

2.4 常见误判信号

3. 两个门户：用户门户 vs 管理员门户的边界

3.1 门户的本质差异

3.2 管理员门户的关键能力

3.3 管理员门户 URL 的构成

3.4 典型访问流程

4. 管理员门户：日常操作的"主入口"

4.1 日常操作覆盖面

4.2 核心磁贴清单

5. 特权终结点 PEP：受限的 PowerShell 应急工具

5.1 是什么

5.2 适用场景

5.3 不能用 PEP 做的事

6. 获取 PEP IP 地址：管理员门户中的标准流程

6.1 标准操作步骤

6.2 何时会用到 PEP IP

7. PEP 三节点分布：ERCS01/02/03 的 HA 拓扑

7.1 三个 ERCS VM

7.2 拓扑示意

7.3 三个 ERCS VM 的可见性

8. 从 HLH / OAW 访问 PEP：可信主机配置

8.1 HLH / OAW 是什么

8.2 添加可信主机

8.3 可信主机的工程解读

9. 建立 PEP 会话：PowerShell Just Enough Administration

9.1 标准命令

9.2 凭据格式

9.3 连接成功提示

9.4 cmdlet 参考

9.5 推荐的工作流

9.6 PEP 的 Token 授权机制（高级用法）

9.6.1 为什么需要 Token

9.6.2 Token 的工程性质

9.6.3 实际工作流

9.6.4 注意事项

10. PEP 的常见误用：三个不该这么做的操作

10.1 在生产时段执行 Repair-Volume / Test-Volume

10.2 在 PEP 内修改网络配置 / 防火墙规则

10.3 把 PEP 当成日常运维工具

11. 区域管理：管理员操作 Azure Stack Hub 的资源单位

11.1 区域是什么

11.2 区域管理的资源范围

11.3 与管理员门户 / PEP 的关系

12. 容量管理界面：管理员门户的容量选项卡

12.1 进入方式

12.2 容量页通常显示什么

12.3 容量阈值的工程含义

12.4 与 PEP 容量查询的区分

13. 四层原则落地：管理员操作的全景分层

13.1 跨版本的演进风险

14. 三大误判信号：管理员日常最容易踩的坑

14.1 误判 #1：PEP 无法 ping 就认为 PEP 故障

14.2 误判 #2：ERCS VM 自动重启就认为"被攻击"

14.3 误判 #3：容量显示"未注册"是首次部署常见状态

14.4 误判 #4（常见但容易被忽略）：StampInformation 文件中终结点不齐全

15. 四条操作红线：管理员绝对不能越的边界

15.1 红线 #1：不修改 OEM 验证过的物理 / 网络配置

15.2 红线 #2：不擅自重启 ERCS VM 或修改 PEP 配置

15.3 红线 #3：不在生产时段做大范围配置变更

15.4 红线 #4：不越过容量阈值强制部署

15.5 配合第 3 篇的"报修"上下文

16. 上篇小结：管理员操作的工程化整合

16.1 核心入口速查

16.2 操作优先级建议（L3 最佳实践）

16.3 与其他两篇的关系

16.4 持续维护建议

附录 A：本文核心 cmdlet / 命令快速参考

附录 B：本文相关资源链接参考

10.1 在生产时段执行 `Repair-Volume` / `Test-Volume`