企业官网建设流程全解析

用 Fleet 把 macOS 26.4 Managed Migration Assistant 落地为可审计、可回滚的声明式迁移策略

【免费下载链接】fleetOpen device management项目地址: https://gitcode.com/GitHub_Trending/fl/fleet

Mac 换机流程中最不可控的一步——旧机数据迁移——如今终于可以被 IT 部门以声明式策略、完整审计记录和 GitOps 版本控制的方式接管。macOS 26.4 的 Managed Migration Assistant 让"哪些数据跟着用户走"从一次用户即兴决定，变成组织层面的策略决策。

导读

每一次硬件刷新，IT 都会面对那个始终没得到答案的问题：旧 Mac 上的哪些数据会跟着用户进入新机器？传统上只有两种选择：干脆禁用迁移功能（激怒用户），或者完全信任用户在键盘前自行决定哪些文件夹、账户、密钥和隐私设置落到企业机器上——而没有任何记录证明到底迁移了什么。

Apple 在 macOS 26.4 中推出的 Managed Migration Assistant 关闭了这个缺口，把迁移从一次不受管控的用户选择，变成由设备管理服务在 Setup Assistant 期间下发的声明式配置（Declaration）。本文将以 Fleet 为落地载体，完整讲解该功能的策略声明结构、状态与审计报告、前置条件、本地管理员凭据的治理难题，以及如何通过 GitOps 工作流把迁移策略当作代码来管理。

迁移一直是部署链路中不受治理的一环

声明式设备管理（DDM）、零接触注册（Zero-touch Enrollment）、配置描述文件、FileVault 强制——现代 Apple 部署栈几乎管住了新 Mac 的一切，唯独差一步：当用户选择把数据从旧机器带过来时，治理戛然而止，剩下的全交给信任。

这个缺口有实打实的后果：

• 安全侧：不受控的迁移可能把个人账户、过期的凭据、SSH 私钥、以及十年无人管理的文件，一起拖进一台刚交付的企业设备。
• 合规侧：面对审计师的"这台设备迁移了哪些数据、在什么时间？"这一基本问题，IT 拿不出任何答案。
• 人性侧：IT 唯一可靠的手段是禁用迁移，这直接导致许多组织至今仍有用户赖在老旧 Intel Mac 上，只因不愿面对手动重建环境的痛苦。

Managed Migration Assistant 第一次让这最后一步也加入了受管理的部署体系。

从用户选择到组织策略：声明式迁移的核心

核心转变一句话就能说清：你描述你想要的迁移，Setup Assistant 负责强制执行。

在 Fleet 的 DDM 体系里，这类声明以 JSON 形式的 DDM profile 为载体。Fleet 对 DDM 的处理围绕"DDM profiles 的定义 → 向目标主机投递 → 服务端与设备之间的状态同步"展开（见 Fleet DDM 架构文档）。迁移声明包含四个关键字段：

路径规则与优先级

路径都是相对于范围内用户的 Home 目录的。例如RequiredPaths中的Documents/Work/会强制迁移该项目目录；而一个排除项（ExcludedPaths）可以从一个本应整体迁移的路径中单独抠出某个子文件夹。

一个对存储受限换机场景特别有用的细节：当你在RequiredPaths中列出多个必迁路径时，顺序即优先级——如果新 Mac 空间不足，最重要的数据会优先落地。

需要围绕边界设计，而非对抗边界

有几条硬性边界值得在设计阶段就考虑，而不是等部署后再跟它较劲：

• 隐藏文件默认迁移，除非你显式排除它们。这包括 SSH 密钥这类你可能非常想留在旧机上的东西。
• 用户的~/Library总是会被迁移，且无法排除。
• /Applications中的条目以及某些系统设置根本不在可迁移范围内，所以给新机器装软件这件事，仍然是你现有应用部署工作流的职责。
• Restore 面板无法隐藏。

这些都不是致命伤，它们只是你设计策略时所在的"盒子"的形状。核心意义在于："哪些数据跟着你走"从此是安全与 IT 团队在策略里一次性做出的决定，而不是用户在上手阶段临时发挥。

你从未拥有过的审计报告：声明式状态通道

最该引起合规团队注意的能力，恰恰是文档中最安静的那一条。

声明式设备状态通道（declarative device status channel）在迁移过程中报告进度，并在传输完成后交付一份报告，其中包含：日期、时间、传输的数据量、以及是否有文件未能迁移。这是第一次，"什么数据在什么时间移动到了这台设备"有了白纸黑字的答案，而不是一个耸肩。

这一变化把迁移从"信任行为"升级为"可审计事件"：

• 它提供了排查部分迁移问题的追踪线索；
• 它给了审计师"数据在刷新过程中遵循了既定、可记录流程"的证据；
• 在受监管环境中，"我们有政策"和"我们有政策 + 政策被执行的记录"之间的差别，就是整场对话的胜负手。

更快的刷新、更少的工单

治理故事是头条，但真正让这个功能被采纳的是操作层面的收益。

Migration Assistant 会自动选择可用的最快传输方式：直连 Wi-Fi、基础设施 Wi-Fi、以太网或 Thunderbolt——并且在传输进行中还会持续检查是否有更快的选项。结合其内嵌于 Setup Assistant 以及通过 Automated Device Enrollment（ADE）实现的零接触注册，受管迁移变成了与设备其他部分完全相同的无人值守供应流程。

这带来了一个值得点名的二阶收益：它降低了刷新成本，足以推动人们最终离开旧硬件。一条受支持、受治理的迁移路径，比"我们会抹掉你的机器，你得从头重建环境"更容易说服不情愿的用户。独立测试还发现，该功能可与比官方 macOS 15 基线早好几个版本的源 Mac 配合工作——如果你的"掉队者"恰恰是你最想淘汰的那些设备，这很有参考价值。

上线前必须先解决的那个前置条件

有一个前置条件将决定这个方案在你的环境里是否可行，而且它是一个权限问题，不是技术问题。

要在源 Mac 上启动迁移，用户必须使用本地管理员凭据进行认证。在用户都是标准用户的组织里，解决办法是把此功能与即时（Just-in-Time）权限提升配合使用，让标准用户能短暂启动 Migration Assistant 而不持有常驻管理员权限。开源工具如 SAP Privileges（macOS-enterprise-privileges）可以解决这个问题。在那些方案都不可行的地方，可以临时调整authorizationdb允许标准用户启动 Migration Assistant，之后再重置回来。无论走哪条路，这都是区分"顺畅上线"与"原地卡住"的规划步骤——在发布策略之前，先决定标准用户如何获得临时权限，而不是等第一次刷新在登录提示符前失败之后。

其余前置条件直白但具体：

• 目标 Mac 需运行macOS 26.4 或更高版本；
• 设备必须受监管（supervised），并通过Apple Business Manager 或 Apple School Manager注册，且指派给某个设备管理服务；
• 声明必须以await_device_configured标记下发，确保在用户到达迁移步骤之前声明就已就位。

await_device_configured在 Fleet 中是自动注册（ADE）配置文件里的一项设置：在 Fleet 的 GitOps YAML 中，它通过setup_experience.apple_setup_assistant指向的自动注册 profile（.json）来配置；如果同时开启了apple_enable_release_device_manually，则由你负责在适当时机下发DeviceConfigured命令放行设备（见 custom-configuration-web-url 文档 中对这一机制的完整编排示例）。目标 Mac 在 Setup Assistant 中完成注册后，Fleet 服务端通过ReconcileAppleDeclarations定时任务把迁移声明标记为 pending、并以DeclarativeManagementMDM 命令触发 DDM 协议交互（见 DDM 交付流程）。

把迁移策略变成代码，而不是控制台里的一次点击

迁移策略太重要了，不该以"六个月前有人在网页控制台里拨了个开关、现在没人记得为什么"的形态存在。

好在声明本身很小：一个ShouldDoManagedMigration标志、一个ShouldMigrateSecurityPrivacySettings标志、加上RequiredPaths和ExcludedPaths两个数组。这份紧凑恰恰是它应该进版本控制的原因。

通过 GitOps 工作流管理迁移策略：

• 策略在合并（pull request）之前经过同行评审；
• 保留"谁在什么时候改了什么、为什么改"的完整历史；
• 刷新出问题的时刻可以即时回滚。

决定"哪些企业数据会落到每一台新 Mac 上"的策略，应该和你的其他任何基础设施一样可审计、可回滚。

在 Fleet 的 GitOps YAML 中组织迁移策略

在 Fleet 中，声明式配置（DDM profiles）与传统的.mobileconfig描述文件、Windows.xml描述文件一样，都可以通过fleetctl gitops用版本化 YAML 管理。配置文件（profile）归属于某个 fleet（或 "Unassigned"），并可通过标签（labels）按条件作用到该 fleet 的主机上（见 DDM 架构文档）。

在 GitOps YAML（docs/Configuration/yaml-files.md）中，把迁移声明作为自定义设置放进macos_settings.custom_settings：

controls: macos_settings: custom_settings: - path: ../lib/macos/managed-migration.json labels_include_all: - All Macs

其中../lib/macos/managed-migration.json即迁移声明文件（DDM 格式的 Apple JSON profile），内容大致为：

{ "Type": "com.apple.configuration.management", "Identifier": "com.fleet.example.mac-migration", "Payload": { "ShouldDoManagedMigration": true, "ShouldMigrateSecurityPrivacySettings": true, "RequiredPaths": [ "Documents/Work/", "Desktop/" ], "ExcludedPaths": [ "Desktop/tmp/" ] } }

说明：以上 JSON 为示意结构，实际键名与 schema 以 Apple 的 DDM 数据模型与 Fleet 上传校验为准。声明一旦上传，Fleet 的ReconcileAppleDeclarations会把变化的主机标记为 pending，随后通过DeclarativeManagementMDM 命令触发 DDM 协议；协议中的tokens、declaration-items、declaration/configuration/{id}、status等端点往返由 Fleet 的DeclarativeManagement接口实现处理，status上报会把声明标记为 verified 或 failed（见 DDM 生命周期 与 commander.go）。

把这段 YAML 提交进 Git 仓库，迁移策略就走上了和其他基础设施代码完全相同的轨道：PR 评审 → CI/CD 应用 → 漂移纠正（drift correction）→ 可回滚。

用 Fleet 实时确认"实际落了什么"

声明式配置的"声明-应用"闭环只是故事的一半。另一半是：声明下发之后，你如何确认它真的生效了？

这正是 Fleet 的用武之地。Fleet 从版本化 YAML 交付 Apple 的声明式配置，通过 CI/CD 应用并带漂移纠正；同时配合 Fleet 代理（fleetd）的实时上报，你可以确认什么真正落到了新设备上，而不是单纯相信声明已下发。在 DDM 协议中，设备在status端点回传声明的应用状态，Fleet 据此把对应 profile 标记为 verified（已验证）或 failed（失败）——这个状态在 Fleet UI 的 "Controls → OS settings → Custom settings" 页面可以随时查看，也支持通过 API 查询：

• GET /api/latest/fleet/configuration_profiles：列出所有配置描述文件（含 DDM profiles）；
• GET /api/latest/fleet/configuration_profiles/{profile_uuid}/status：查看某个自定义设置的按状态统计；
• GET /api/latest/fleet/configuration_profiles/summary：fleet 级自定义设置状态总览。

配合前文的状态通道报告（日期、时间、数据量、未迁移文件），你同时拿到了两个维度的证据：设备侧声明的应用状态（Fleet 的 verified/failed），以及迁移本身的结果报告（状态通道）。两者叠加，迁移从"信任练习"变成了完整的可审计事件。

结语：赌注是什么

迁移曾是整个受治理部署链路里最后一步不受管控的环节；而"不受管控"恰好发生在决定哪些数据落到新企业设备上的那一步，这从来不是一个让人舒服的位置。Managed Migration Assistant 不仅让刷新更顺畅，它把迁移决策带入了与其他一切部署内容相同的策略、审计与版本控制体系之下。

那些把它当作治理能力而非便利功能来对待的组织，将同时收获审计轨迹和干净基线。在 Fleet 中落地时，请从以下几件事开始：

1. 确认目标 Mac 满足 macOS 26.4+、受监管、ABM/ASM 注册且指派到 Fleet 的前置条件；
2. 提前设计标准用户的即时权限提升方案（SAP Privileges 或authorizationdb临时调整）；
3. 把迁移声明写成 JSON 文件放进 Git 仓库，通过macos_settings.custom_settings下发；
4. 确保自动注册 profile 设置了await_device_configured，让声明在用户到达迁移步骤前就位；
5. 用 Fleet 的 profile 状态与状态通道报告验证"实际落了什么"。

延伸阅读

• Fleet DDM 架构与生命周期：DDM profiles 的管理、投递、验证全流程
• GitOps YAML 配置参考：macos_settings、setup_experience、macos_migration等全部字段说明
• custom-configuration-web-url 编排示例：await_device_configured与DeviceConfigured命令的完整配合流程
• Apple MDM commander 实现：Fleet 侧 MDM 命令入队与推送的实现

【免费下载链接】fleetOpen device management项目地址: https://gitcode.com/GitHub_Trending/fl/fleet