先给结论：iOS 27 之后，用备份恢复不会再把管理状态带回来；这台设备能不能重新被纳管，只取决于它的序列号在不在你的企业账号里，跟备份里存了什么无关。
这条变化是我们在做一次设备回收翻新的时候发现的。同样的机型、同样的操作流程，一部分机器恢复完之后直接跳出受监督的管理界面，另一部分恢复完是个干净的基础桌面。一开始以为是我们这边的策略没生效，查下来是系统版本的问题------跑在 iOS 27 上的那一批，恢复之后一律不再携带管理状态。
为什么会被分成两类
要理解这条变化，先要理解管理关系到底放在哪里。它不在本机上，它在苹果服务器上，锚点是这台设备的序列号。本机上的描述文件、限位策略这些东西，是这条服务器记录的本地投影，不是记录本身。
以前的做法是：备份文件里除了用户数据，还会连这份本地投影一起存下来，恢复的时候一并写回。结果是同一份备份恢复到不同的机器上，管理状态会跟着漂移，甚至会出现一台机器带着别人的管理配置在跑。这在单台设备上感觉不出来，在几百台的规模上就是一堆对不上的台账。
底层变化在于：新版本把管理状态从「备份可以携带的东西」这一类里移出去了。现在的恢复流程只还原用户数据，管理这部分必须由激活或注册流程重新去问一次服务器。服务器回答「归某家企业管」，这台机器就重新走一遍纳管；服务器那儿没有这条记录，恢复完就是一台干净的机器。
之所以这么改，是因为序列号那条记录是不变量，而本机上的投影是可变量，让一个可变量去决定一个不变量的归属，必然会出现两边对不上的情况。改完之后，归属只有服务器一个来源，不会再有第二个。
纳管方式不同，恢复之后的结果相反
这条改动对不同纳管方式的设备影响完全相反，差别在于序列号有没有真的进到企业账号里。
（下表按纳管方式、iOS 27 前的恢复结果、iOS 27 后的恢复结果三项对照）
- 开箱自动注册｜恢复后管理状态多数还在，偶尔漂移｜每次恢复都重新走一遍注册，稳定回来
- 手工安装描述文件｜恢复后有时会带回来一份失效的旧配置｜恢复后不再有任何管理状态
- 未纳管过的零售机｜无变化｜无变化，恢复完仍是普通设备
第一行是受益的一方------以前靠运气的事情现在变成了确定行为，只要序列号在企业账号下、且分配指向的服务器还在工作，恢复多少次都会回来。
第二行是受损的一方，也是这次调整里要重点处理的一批。这些机器本来就没真正注册进来，之前靠备份漂移「看起来还在」，现在这层遮罩没了，真实状态暴露出来：它们其实一直没被管住。
恢复之前要核的三样东西
既然归属由服务器决定，动手之前核的就是服务器那一侧的三样。 - 序列号在企业账号的设备列表里：不在的先补收录，之后再谈恢复
- 该序列号被分配到了哪一台服务器：分配错了会在错误的那套系统里重新纳管
- 连接门户的服务器令牌还有多少天：它的有效期是 365 天，过期状态下列表不再同步
第三样最容易被忽略。令牌这件事的特点是它平时完全没存在感，直到某一天设备列表停止更新才被发现。而且它不像密码那样到期会提醒，只在过期之后安静失效。建议把它的到期日单独做成一个看得见的东西，别放在某一个人的记忆里。
MDM.Plus 的台账在「最后心跳时间」这个字段之外，还单独留了纳管方式和注册来源两项，就是为了区分这两种情况------同样是离线，一种是临时断网，一种是恢复完之后再也回不来了。
误区纠正
误区一，认为这条变化让管理变松了。相反，它把「看起来纳管」和「真的纳管」区分开了。以前靠备份漂移维持的那部分，本来就是假的。
误区二，以为恢复之后什么都不用做。自动注册的设备确实会自动回来，但回来的只是纳管关系，策略生效需要一次推送通道的完整握手。推送证书过期的情况下，关系回来了、策略下不去，这种状态比完全没回来更难发现。
误区三，把它当成升级之后要重装全机队的理由。要不要动，取决于你这批机器的纳管方式分布。先抽样本查纳管来源，再决定是批量动作还是只处理那一小批。
两条适用边界
第一条，这条变化只在 iOS 27 及之后的系统上成立。还留在旧版本上的机器沿用旧行为，备份里那份管理配置依然会被写回。所以机队要按系统版本分成两堆，两边的处置流程不能共用。
第二条，这里说的是「从备份恢复」这个动作，不等于直接抹除。抹除走的是另一条路径，它不依赖备份内容，这两种场景不要放在一起讨论。
给同行的一个自验判据
找一台跑 iOS 27 的自动注册设备，先做一次完整备份，再执行一次恢复，然后依次看三处：设置里的设备管理条目有没有重新出现、最后心跳时间有没有刷新、以及限制策略是不是又开始生效了。 - 三处都正常：这一批可以按自动回归处理
- 条目出现了但心跳不刷新：推的一层有问题，先查证书
- 条目没出现：查纳管来源，大概率是手工装的那一批
第二行是最容易被误判的情况。很多人看到管理条目还在就以为没事，但实际上策略已经下不去了，这台机器在台账里会一直显示在线。
把有可能受影响的机器提前分出来
知道机制之后，实际操作就剩一件事：把可能被这一步影响到的机器挑出来。
按三个条件筛：系统版本已经是 iOS 27 或之后、最近 30 天内有过一次抹除或恢复记录、纳管来源不是自动注册。三条里命中两条的进入人工复核名单。
抽样比例建议按总量取 10%，但不少于 20 台、不多于 100 台。低于 20 台样本代表性不足，高于 100 台则投入产出比开始下降，因为批量执行的结果偏差通常在几次之内就能看到。
复核完之后，把结果按纳管来源分两堆统计，得到两个比例：自动注册设备的回归成功率、手工安装设备的回归成功率。这两个数决定了后面是批量动作还是逐台处理。 - 自动注册那堆的成功率高于 95%：可以按批次推，只核对异常的那几台
- 手工那堆的成功率低于 30%：这一批要重新走纳管，不能指望恢复自动带回来
- 两堆差值很大：说明纳管口径本身不统一，这是个比恢复更早要解决的问题
第三种情况在我们的经验里最常见，而且它通常被误判成系统有问题。实际上系统是按规则办事的，有问题的是当初的纳管口径没有统一。
还有一个容易忽略的时间项：推送证书的有效期是 365 天。如果回归之后设备在线、策略却一直不生效，先查这个到期日，它比纳管关系本身更容易被漏掉。