Azure 门户 vs. ARM 模板 部署差异详解（azloc-2606）
"Azure 本地系统的 ARM 模板部署面向大规模部署。此部署的目标受众是具有部署 Azure 本地实例经验的 IT 管理员。建议先通过 Azure 门户部署系统，然后通过 ARM 模板执行后续部署。"
所以两者不是并列二选一 ，而是入门 → 进阶的关系。
1. 模板版本与 azloc 适配
| 项 | Azure 门户 | ARM 模板 |
|---|---|---|
| azloc-2606 支持 | ✅ | ✅（2503 起切到 create-cluster 模板） |
2. 核心差异对照表
| 维度 | Azure 门户 | ARM 模板 |
|---|---|---|
| 目标受众 | 第一次/一次性部署 | 大规模、批量、自动化部署 |
| 入门方式 | 门户搜索 "Azure 本地" → 创建实例 | 门户 → 创建资源 → 模板部署 → 自定义模板 |
| 配置来源 | 新配置 / 模板规格 / 快速启动模板（快速启动本版本没有） | azuredeploy.parameters.json（GitHub 仓库里的快速启动模板） |
| 依赖服务主体 | 不需要 | 需要（ARB 服务主体 + 客户端机密 + hciResourceProviderObjectID） |
| 参数数量 | 表单字段（约 30 个） | JSON 参数文件（约 60+ 个，含安全/遥测/SBE/Partner 等） |
| 拓扑覆盖 | 仅已验证的网络拓扑表里 ✅ 的组合 | 全部已验证组合（包括 3/4 节点无交换机） |
| 存储 IP 自定义 | 不允许（用 Network ATC 默认） | 允许 （enableStorageAutoIp + 自定义 IP） |
| 见证类型控制 | 仅 2 节点隐含云见证 | 显式 witnessType 参数 |
| 安全参数粒度 | 只能选"建议"或"自定义"档 | 逐项控制：Credential Guard / SMB 签名 / SMB 集群加密 / BitLocker 启动+数据卷 / WDAC / driftControl |
| 遥测参数 | 隐藏 | streamingDataClient/euLocation / 事件化数据上传 |
| SBE 控制 | 隐式 | 显式 sbeVersion / sbeFamily / sbePublisher / sbeManifestSource / sbeManifestCreationDate |
| Partner 属性 | 隐式 | partnerProperties / partnerCredentialList 显式传入 |
| 部署流程 | 单步向导：填写 → 验证 → 创建 | 两步法 ：先 部署模式=验证（≈10 min）→ 再切 部署模式=部署 |
| 耗时（4 节点参考） | 2.5--3 小时 | 2.5--3 小时（最长步骤"部署 Moc 和 ARB Stack"需 40--45 分钟） |
| 失败恢复 | 门户内"恢复部署"按钮 | 改参数 JSON 重新部署 |
| 审计 / 合规 | 手工记录 | JSON 入 Git / CI/CD 流水线，可审计、可回滚 |
| 可重复性 | 低（手工重复） | 高（参数文件即 IaC） |
| 支持的网络模式 | 受限于门户下拉选项 | 完全开放（含 portal 不支持的所有拓扑） |
3. ARM 模板独有的"额外负担"
官方原文明确点出 ARM 模板比门户多了 3 步手工准备：
3.1 服务主体 + 客户端机密（门户自动，模板必须自己建）
若要对系统进行身份验证，需要为 Arc 资源桥（ARB）创建服务主体和相应的客户端机密。
参数：
arbDeploymentAppID= 应用（客户端）IDarbDeploymentSPNObjectID= 对象 IDarbDeploymentAppSecret= 客户端机密值（页面关掉就再也看不到，当场复制）
⚠️ 坑点 ：Entra ID 的"客户端机密"离开页面就不可恢复------必须立刻复制到 Key Vault 或 password manager。
3.2 hciResourceProviderObjectID
Azure 本地资源提供程序（RP）的此对象 ID 对于每个 Azure 租户是唯一的。
查法：
(Get-AzADServicePrincipal -ApplicationId "00001111-aaaa-2222-bbbb-3333cccc4444").Id或
az ad sp list --filter "appId eq '00001111-aaaa-2222-bbbb-3333cccc4444'" --query "[0].id" -o tsv3.3 两阶段部署（Verify → Deploy）
官方原文：
- 滚动到底部，确认
部署模式 = 验证。- 选择查看 + 创建。验证需要大约 10 分钟才能完成。
- 验证完成后，选择"重新部署"。
- 在工作区底部，将 JSON 中的最终值从"验证"更改为**"部署"**。
→ 这是 ARM 模板特有的两步，门户是单步。
4. ARM 模板"已知问题"（门户没有这些坑）
官方页面专门列了 3 条已知问题（azloc-2606）：
| 问题 | 触发条件 | 解决方法 |
|---|---|---|
| 角色分配已存在 | 先门户后 ARM 用同一资源组 | 去资源组 IAM 删除 AzureStackHCIDeviceManagementRole-RoleAssignment |
| 租户 ID / 应用 ID / 主体 ID / 范围 不允许更新 | 旧部署资源删除后僵尸角色分配残留 | IAM → 角色分配 → 类型=未知 → 删"找不到标识" |
| 许可证同步问题 | 系统处于"部署失败"时再起一个验证模式部署 | 不要在失败状态下重启验证模式 |
→ 这些问题只在你 portal + ARM 混用、或反复重部署时才会出现。
5. 部署后的差异
| 项 | 门户 | ARM 模板 |
|---|---|---|
| Entra ID 应用创建 | 2503 起门户已不再创建 Entra 应用（用系统分配托管标识） | 同（统一从 12.2512 版本起都用系统分配托管标识） |
| 资源组里看到的资源 | 相同：每节点 1 个 Arc Computer、1 个 Azure Local、1 个 ARB、1 个 InfraLNET、1 个 KV、1 个 Custom Location、2 个 Storage Account（云见证 + KV 审计日志）、每个工作负荷卷 1 个 Storage Path | 完全相同 |
→ 最终落到订阅上的资源布局一致。门户/ARM 只是入口不同。
6. 你的场景选哪条路
假如场景是新部署的 4 节点 + Dell S5224F-ON ：
| 条件 | 评估 |
|---|---|
| 节点数 | 4 ✅ 都在 |
| 存储交换机 | 有 ✅ 都在 |
| 4 节点有交换机 | 门户 ✅ / ARM ✅（门户是首选） |
建议路径：
第一次（学习曲线） ──▶ Azure 门户（你当前选的）
后续扩容 / 多站点 / 灾备 ──▶ ARM 模板（参数化、CI/CD、版本控制）
POC / 测试 ──▶ Azure 门户
生产多集群 ──▶ ARM 模板7. 总结
门户 = 人工驾驶；ARM = 自动驾驶。两者都支持 azloc-2606，门户是入门，ARM 是规模化。