抹除之后机器上的受管应用可以留下:这一步省掉的是哪段时间

先给结论

新一代系统里,走「回到可用状态返还」这条抹除路径时,机器上已经装好的受管应用可以被保留下来,不用重新下一次。 省掉的不是安装本身,是「抹完到能用」之间的那段等待。这一段在多门店调拨里最值钱,因为它直接压在周转天数上。

这条路径是什么

「回到可用状态返还」是苹果在受监督设备上提供的一条抹除路径。它和普通抹除的区别在于目标:

  • 普通抹除的目标是「把机器清空」;
  • 这条路径的目标是「把机器清空到能马上交给下一个人」,并且在这个过程中保持或重建管理关系。

对租赁商家来说,这个区别很实际。一台机器从客户手里回来,要经过清数据、解绑、检查、再交付几个环节。这条路径覆盖的是中间那段:清掉上一个人的痕迹,把机器送回可交接的状态,同时不让管理关系在中间丢掉。

三层机制:应用为什么能留下

第一层:现象层

抹完之后机器回到初始设置流程,走完之后桌面上的受管应用还在。过去这一步是空的------抹完就是一台干净的机器,应用要重新推一遍。

第二层:直接原因层

应用在不在,取决于它归谁管、按什么方式分发。

  • 按设备分发的应用,许可挂在这台机器上而不是挂在某个人身上,因此机器还是这台机器的时候,许可关系可以继续成立;
  • 按用户分发的应用就不行------使用者已经变了,许可要重新绑定。

第三层:底层机制层

这条路径之所以能保留,是因为它把「清数据」和「保留机构资产」拆成了两件事来做。数据属于上一个人,必须清;应用属于机构,可以留。过去这两件事被绑在一起,是因为抹除命令只有一个粒度。现在粒度细了一层。

一个必须记住的变化:备份恢复不再带回管理关系

这里有一条容易和新能力混在一起的变化,方向恰好相反。新一代系统起,设备从备份恢复时不再恢复设备管理注册关系------包括注册描述文件、管理配置与受监督状态。在苹果后台登记过的设备,改由自动设备注册在恢复后重新纳管。

这两件事要放在一起理解:

  • 抹除路径这条线在「多保留一点」;
  • 备份恢复这条线在「少带回一点」。

它们的共同点是都把「数据」和「管理关系」分开了,区别是前者保留机构侧的东西,后者不再恢复用户侧带过来的东西。做过旧版恢复流程的商家,这一步要重新审一遍。

三个自验动作

动作一,确认应用的分发方式。 把这台机器上的受管应用列出来,逐个看是按设备分发还是按用户分发。只有按设备分发的那部分有可能留下。这一步在分发记录里就有,不用逐台看机器。

动作二,抽 3 台样机跑一遍完整路径。 发起抹除、走完设置助理、进入桌面,全程计时。把「发起」到「桌面上的应用可用」这一段单独记下来,这就是省掉的那段时间。3 台跑完大约 30 分钟。

动作三,对照一次。 找一台走普通抹除的机器,同样计时。两个时间相减,就是这个能力在自己流程里的实际价值。不同机型与网络条件下这个差值会变,因此要按自己的盘子测,不能套别人的数。

两个容易误判的地方

误判一,以为所有应用都会留下。 按用户分发的那部分不会。判断标准只有一条:许可挂在机器上还是挂在人身上。

误判二,以为留下来就不用管了。 留下的是应用本身,应用的数据、登录状态、缓存这些属于上一个人,必须清掉。留应用不等于留数据,这两件事在新路径里是分开处理的,验收时要分开验。

在 500 台规模的机队里,按分发方式分组统计一次大约需要 30 分钟,导出后一次就能算出「有多少比例的应用能留下」。

MDM.Plus 的设备台账把纳管方式与描述文件状态分成两列,发起这类抹除前按这两列筛一遍,未受监督的设备会被直接标出来,不会混进批量命令里。

为什么省下的那段时间在多门店里最值钱

原因是这样------单店场景下,抹完之后重新推应用这段时间里,店员可以去做别的事,时间成本被摊掉了。多门店调拨场景不一样:机器要从 A 店发到 B 店,等到应用可用才能交付,这段时间直接压在在途天数上。机制上,它把一个人的等待变成了整个链路的等待。

依赖的前提是应用的分发方式以按设备为主。按用户分发的那部分留不下来,按设备分发的才能留。

链路是四段:

  1. 确认分发方式;
  2. 发起抹除;
  3. 走完设置助理;
  4. 校验应用可用。

第一段最容易漏,漏了后面三段做完了也白做。

按每月调拨 20 台、每台省 30 分钟算,一个月约 10 小时。这个数在单店模型里可以忽略,在跨城调拨里能顶掉半个人工日。

给同行的一个自验判据

判据可以落成四条:

  1. 逐个确认受管应用的分发方式,只有按设备分发的可能留下;
  2. 抽 3 台样机跑完整路径并分段计时;
  3. 与普通抹除做一次对照,得出自己的实际差值;
  4. 单独验一次数据有没有清干净,留应用不等于留数据。

四条里第四条最不能省------它牵涉的是上一个客户的个人信息,不是效率问题。

MDM.Plus 的结清退出按固定五步走,第二步清除个人数据有独立的回执记录,做上面第四条时可以调出这份回执核对,不靠肉眼看桌面。

边界与不适用条件

本文讨论的是受监督设备上「回到可用状态返还」这条抹除路径,未受监督的设备不适用。保留受管应用的具体可用版本取决于设备系统版本与管理平台的支持进度,落地前应当以自己所用平台的文档为准。文中 3 台样机与 30 分钟为抽样建议,不是统计样本量要求。本文不涉及共享设备场景下的用户配额与缓存策略,那部分有独立的容量与登录约束。本文也不涉及备份恢复这条路径的完整操作步骤,该流程应当按自己所用平台的现行文档执行。

相关推荐
自由彩虹2 小时前
靶场通关15--bossplayersctf
linux·服务器·网络·安全·web安全·网络安全
2401_868534782 小时前
网络规划设计师之案例分析 - 网络安全与等级保护
服务器·网络
雾时之林2 小时前
Nginx反向代理与proxy_cache缓存搭建CDN服务器
服务器·nginx·缓存
李纲明3 小时前
WordPress 定时发布不准点或备份/邮件从不跑:先分清 WP-Cron 触发与 DISABLE_WP_CRON,再查回环与系统 Cron
运维·性能优化·wordpress·定时任务·devdiy·wp-cron
Decay__3 小时前
01_MySQL 体系架构全解 —— 连接层、SQL 层、存储引擎层与 InnoDB 深入
运维·数据库·sql·mysql·架构
Hello.Reader3 小时前
Three.js / Cesium 卡顿怎么办?把三维渲染搬到 GPU 服务器
服务器·开发语言·javascript
Linux_cy3 小时前
nginx 502 排查手册:九种原因分类、定位命令与检查顺序
linux·运维·服务器·网络·数据库·nginx·ssh
tedcloud1233 小时前
Docker Compose 部署 Uptime Kuma:配置 HTTPS、QQ 邮箱告警与数据备份
服务器·网络协议·ui·docker·容器·https·开源
椒颜皮皮虾྅3 小时前
模型部署不再卡在环境上:DeploySharp 四大推理引擎与 Windows/Linux 离线交付实战
linux·运维·开发语言·人工智能·windows·计算机视觉·cuda