macOS 27 面向 Mac 管理员：MDM 更新命令移除，TLS 要求更严格

Q: 什么替代了推荐节奏设置？

在 macOS 上，没有直接的替代品。苹果的 schema 把声明式 RecommendedCadence 键标记为 macOS 不可用。请用延迟设置来隐藏版本，用强制安装声明来要求安装你想要的版本。

macOS 27 移除了旧版 MDM 软件更新命令，并会阻断不满足新 TLS 规则的管理服务器。哪些功能会失效、如何排查、用什么替代。

如果你负责管理 Mac，macOS 27 Golden Gate 带来了两处改动——它们不会出现在任何用户的屏幕上，却能在一天之内让打补丁流程或注册流程瘫痪。首先，大多数机队用了十年的 MDM 软件更新命令、查询和限制，在运行 27.0 的设备上不再起作用。其次，管理路径中的每一次连接——MDM、声明式设备管理（Declarative Device Management）、自动化设备注册（Automated Device Enrollment）、描述文件安装、应用安装和软件更新——现在都会拒绝不满足 App Transport Security 规则的服务器，而早期版本对此只会记录警告。

这两处改动都不是什么新消息，苹果在 WWDC 2026 之前和会上都已经宣布过。但既然 27.0 已经发布（9 月 14 日，build 26A428），只要 Mac 升级，这些改动就会立即生效。本指南将依据苹果自己的 schema 和支持文档，梳理哪些功能会失效、如何在第一批 Mac 遇到问题之前排查你的服务器，以及每种旧机制分别由什么替代。

核心要点

旧版软件更新管理在 27.0 上已经失效。 苹果官方原文：「Legacy software update management no longer functions in all 27.0 operating systems.」这涵盖了 ScheduleOSUpdate、ScheduleOSUpdateScan、AvailableOSUpdates 和 OSUpdateStatus 命令，com.apple.SoftwareUpdate payload，以及各类延迟限制。
替代方案是声明式的。 softwareupdate.enforcement.specific 会在截止日期前强制安装指定版本。softwareupdate.settings 负责延迟、自动操作、Background Security Improvements 和 Beta 注册。状态项（Status Items）取代了原来的查询。
推荐节奏（Recommended Cadence）在 macOS 上没有对应替代。 苹果的 schema 将声明式 RecommendedCadence 键标记为 macOS 不可用。
管理路径现在会强制执行 TLS 规则。 具体要求是 TLS 1.2 或更高版本、支持前向保密的密码套件、经 SHA-2 签名且 RSA ≥ 2048 位或 ECDSA ≥ 256 位的证书，以及扩展主密钥（Extended Master Secret）扩展。只有 SCEP 服务器和内容缓存服务器可以豁免。
你可以在设备升级之前完成排查。 在更早的系统版本上，同样的检查只会记录警告。苹果文档提供了用来查找这些警告的日志谓词（predicate）。

变化一：旧版软件更新管理已失效

苹果在 WWDC 2026 设备管理更新中用一句话讲清楚了这件事：「Legacy software update management no longer functions in all 27.0 operating systems.」随后列出了具体涵盖范围：软件更新命令、软件更新查询、推荐节奏设置，以及包括延迟和 Background Security Improvements 在内的软件更新限制。

苹果发布的设备管理 schema——也就是 MDM 厂商据以开发的 apple/device-management 仓库中的 YAML 文件——给出了每一项的确切状态。针对 macOS：

旧版机制	Schema 状态（macOS）	声明式替代方案
`ScheduleOSUpdate` 命令	26.0 弃用，27.0 移除	`com.apple.configuration.softwareupdate.enforcement.specific`
`ScheduleOSUpdateScan` 命令	26.0 弃用，27.0 移除	不再需要——设备会自行扫描并上报状态
`AvailableOSUpdates` 查询	26.0 弃用，27.0 移除	状态项 `softwareupdate.pending-version`
`OSUpdateStatus` 查询	26.0 弃用，27.0 移除	状态项 `softwareupdate.install-state`、`softwareupdate.failure-reason`、`softwareupdate.install-reason`
`com.apple.SoftwareUpdate` 描述文件 payload	26.0 弃用，27.0 移除	`com.apple.configuration.softwareupdate.settings`
限制项 `forceDelayedSoftwareUpdates`、`forceDelayedMajorSoftwareUpdates`、`forceDelayedAppSoftwareUpdates`、`enforcedSoftwareUpdateDelay`	26.0 弃用，27.0 移除	`softwareupdate.settings` → `Deferrals`

我们使用的 schema 快照取自该仓库 release 分支在 2026 年 9 月 18 日的版本。如果你的 MDM 厂商控制台仍然显示这些旧版选项，那是给运行 26.x 及更早版本的设备用的。在运行 27.0 的 Mac 上，它们不会产生任何效果。

声明式设置涵盖的内容

softwareupdate.settings 配置是大多数旧版限制项迁移后的落脚点。以下是根据苹果 schema 整理的顶层键：

键	作用
`Notifications`	用户是否能看到更新通知
`Deferrals`	`CombinedPeriodInDays`、`MajorPeriodInDays`、`MinorPeriodInDays`、`SystemPeriodInDays`
`AutomaticActions`	`Download`、`InstallOSUpdates`、`InstallSecurityUpdate`
`RapidSecurityResponse`	`Enable`、`EnableRollback`——在 schema 中被标注为「Background Security Improvements settings」
`AllowStandardUserOSUpdates`	非管理员用户是否可以安装系统更新
`Beta`	`ProgramEnrollment`、`OfferPrograms`、`RequireProgram`，用于 AppleSeed 和开发者 Beta
`RecommendedCadence`	在 schema 中被标注为 macOS「n/a」（不适用）

schema 中还提到，Background Security Improvements「不受 Major、Minor 或 System 延迟机制的约束」。也就是说，针对主要版本的延迟设置并不会拖延后台安全修复。如果你需要控制这部分内容，要用 RapidSecurityResponse 键。我们的Background Security Improvements 指南详细解释了这类更新是什么。

在 27.0 上强制安装指定版本

强制安装声明是你会用得最多的一种。它指定一个目标版本和一个截止时间：

{
  "Type": "com.apple.configuration.softwareupdate.enforcement.specific",
  "Identifier": "com.example.su.macos-27-0-1",
  "Payload": {
    "TargetOSVersion": "27.0.1",
    "TargetLocalDateTime": "2026-10-15T18:00:00",
    "DetailsURL": "https://intranet.example.com/updates"
  }
}

TargetOSVersion 和 TargetLocalDateTime 是核心键。此外还有用于锁定具体构建版本的 TargetBuildVersion，当两者同时设置时以它为准。示例中的版本号只是示意——截至本文撰写时，27.0.1 尚未发布。你的 MDM 厂商通常会提供表单而不是原始 JSON，但了解这些键的含义，能帮助你在查看设备状态中的声明、排查安装失败原因时更快找到问题所在。

同一策略的两种写法

一个具体的例子能让这次迁移更容易理解。以一条常见策略为例：把主要版本升级延迟 30 天，同时保持自动下载和安全更新处于开启状态。

旧版写法是 com.apple.applicationaccess payload 中的一组限制键：

<key>forceDelayedMajorSoftwareUpdates</key>
<true/>
<key>enforcedSoftwareUpdateMajorOSDeferredInstallDelay</key>
<integer>30</integer>

运行 Tahoe 的 Mac 会遵守这条设置，运行 Golden Gate 的 Mac 则会直接忽略它。

声明式写法把同样的意图放进一个配置里：

{
  "Type": "com.apple.configuration.softwareupdate.settings",
  "Identifier": "com.example.su.settings",
  "Payload": {
    "Deferrals": { "MajorPeriodInDays": 30 },
    "AutomaticActions": {
      "Download": "AlwaysOn",
      "InstallSecurityUpdate": "AlwaysOn"
    }
  }
}

在你动手写自己的配置之前，苹果 schema 中有三个细节值得了解：

延迟值的范围是 1 到 90 天，与旧版延迟键的范围一致。
当多个声明设置了同一个键时，设备会按规则进行合并。 延迟项使用 number-max（取最长的延迟时间），自动操作使用 enum-last，Notifications 使用 boolean-and——只要有一个声明关闭了通知，通知就会被关闭。一个遗留下来、设置了 90 天延迟的测试声明会悄无声息地覆盖你 30 天的策略，所以在排查其他问题之前，先检查一下设备上到底分配了哪些声明。
自动操作的取值为 Allowed、AlwaysOn 或 AlwaysOff，默认值是 Allowed。苹果 schema 中把 AlwaysOn 描述为「always enabled（始终启用）」，把 AlwaysOff 描述为「always disabled（始终禁用）」。如果你想把选择权留给用户，就选 Allowed。

读取回执结果

声明式管理通过状态项而非查询来上报状态。softwareupdate.install-state 有五种取值：none、downloading、prepared、installing 或 failed。再配合上说明设备打算安装什么版本的 softwareupdate.pending-version，以及出问题时的 softwareupdate.failure-reason，这些加起来就是旧版 OSUpdateStatus 查询能告诉你的全部信息。而且设备是在状态发生变化时主动发送，而不是等你想起来去问。

混合机队陷阱

未来一年里，你的机队会同时存在运行 Tahoe 26.x、仍然遵守这些已弃用旧机制的 Mac，以及运行 Golden Gate 27.0、完全忽略它们的 Mac。这会带来三种风险：

只有一半生效的延迟设置。 旧版 forceDelayedMajorSoftwareUpdates 限制仍然能拦住 Tahoe 上的 Mac。而一旦 Mac 升级到 27，只有声明式的 Deferrals 设置才对它起作用。如果你想在两边都执行同一策略，就得在两个地方都定义它。
报表变成空白。 基于 OSUpdateStatus 和 AvailableOSUpdates 响应构建的仪表盘，在 27.0 设备上什么都显示不出来。在这些设备被标记为「unknown」之前，把你的报表切换到声明式状态项。
假定命令已经生效的脚本。 发送 ScheduleOSUpdate 并等待结果的自动化流程，在 27.0 的 Mac 上会永远等下去。检查你的运维手册以及所有调用 MDM 的 API 脚本，看看是否还在调用旧版命令。

最简单的做法是现在就把所有 Mac 都迁移到声明式软件更新管理，包括仍在 Tahoe 上的设备——DDM 软件更新声明在那上面已经可以正常使用。旧版设置只作为暂时无法迁移的设备的安全网保留。我们的为什么 macOS 27 没有出现在软件更新中一文详细介绍了延迟设置是如何决定升级是否会被提供的。

两组 Mac 并排接收不同种类的更新策略

变化二：管理路径的 TLS 要求更严格

苹果在其支持文章 Prepare your network environment for stricter security requirements（发布于 2026 年 6 月 9 日）中公布了这些要求，并在 macOS 27 发行说明中重申。管理路径中的服务器必须满足：

要求	详情
协议	TLS 1.2 或更高版本；「尽可能」使用 TLS 1.3
密码套件	前向保密——任意 TLS 1.3 套件，或带 ECDHE 的 TLS 1.2 套件
证书密钥	RSA 至少 2048 位，ECDSA 至少 256 位
签名哈希	SHA-2，摘要长度至少 256 位
TLS 1.2 扩展	扩展主密钥（Extended Master Secret，EMS），RFC 7627

受影响的工作流程，按苹果列出的顺序：移动设备管理（mobile device management）、声明式设备管理、自动化设备注册、描述文件安装、应用安装（包括企业应用分发），以及软件更新。

文档中明确列出了两种例外情况：在安装描述文件或解析 DDM 资产时连接到 SCEP 服务器，不受影响；内容缓存服务器同样不受影响，即便它们提供的是应用或软件更新相关的资源。

27.0 上真正发生变化的是后果。苹果文章原文：「Non-compliant connections are blocked and the log messages appear as errors instead of warnings.」检查机制本身并不是新东西——更早的系统版本已经会把这些违规记录为警告，这也正是现在可以提前排查的原因。

老旧 TLS 藏身何处

公开的 MDM 服务多年来一直是合规的。真正的风险在于你自己托管或放进这条路径里的东西：

自建 MDM 部署在较旧的反向代理或负载均衡器之后，其 TLS 配置一旦设好就再没人碰过
内部应用分发——托管企业应用清单以及 .ipa 或 .pkg 文件的服务器
软件包和资源托管服务器，即 DDM 资产声明或自定义安装流程指向的目标
进行 TLS 检查的防火墙和代理，它们会用自己的证书重新签发流量，而这些证书同样必须满足相同的密钥长度和哈希要求
老旧的证书链——内部 CA 上使用的 RSA 1024 位密钥或 SHA-1 签名
老旧的 TLS 协议栈，能协商 TLS 1.2，却不支持扩展主密钥扩展

在 Mac 升级之前如何排查

第一步：用 `nscurl` 测试每台服务器

macOS 自带了一个 ATS 测试工具，把它指向管理路径中的每一台服务器：

nscurl --ats-diagnostics https://mdm.example.com

它会依次尝试一系列 ATS 配置下的连接，并为每一项打印 Result : PASS 或 Result : FAIL。这里最关键的是第一块结果，Default ATS Secure Connection。作为一次基本验证，我们在一台 Tahoe Mac 上针对两台公开服务器做了测试：www.apple.com 通过了全部 61 项检查；而一台只提供 TLS 1.0 的公开测试服务器则一项都没通过，从默认安全连接这一项开始就失败了。

第二步：检查扩展主密钥

nscurl 不会单独列出 EMS 检查结果，而这恰恰是老旧 TLS 协议栈最容易漏掉的一项要求。OpenSSL 3.x 会直接报告这项信息。macOS 系统自带的 openssl 实际上是 LibreSSL，所以要用通过 Homebrew 安装的版本：

echo | openssl s_client -connect mdm.example.com:443 -tls1_2 -servername mdm.example.com 2>/dev/null \
  | grep -E "Protocol|Cipher|Server public key|Extended master secret"

针对 www.apple.com 运行时，会打印出 Protocol: TLSv1.2、ECDHE-RSA-AES256-GCM-SHA384 密码套件、2048 位服务器密钥，以及 Extended master secret: yes。你需要让路径中的每一台服务器都达到这个水平，或者更好。

第三步：让设备自己告诉你

逐台测试服务器，只能覆盖你已知的那些服务器。苹果推荐的排查方法则通过记录设备实际连接的目标，把剩下的部分也一并捕捉到：

在一台测试 Mac 上安装苹果的 Network Diagnostics Logging 描述文件。
运行你关心的工作流程：注册、描述文件安装、应用安装、软件更新。
从这台 Mac 上采集一份 sysdiagnose。
用苹果给出的谓词搜索日志归档：

log show --archive system_logs.logarchive --info -P "p=appstoreagent|appstored|managedappdistributionagent|managedappdistributiond|ManagedClient|ManagedClientAgent|mdmclient|mdmd|mdmuserd|MuseBuddyApp|NanoSettings|Preferences|profiled|profiles|RemoteManagementAgent|remotemanagementd|Setup|'Setup Assistant'|'System Settings'|teslad|TVSettings|TVSetup|XPCAcmeService AND s=com.apple.network AND m:'ATS Violation'|'ATS FCPv2.1 violation'"

在运行 26.x 的 Mac 上，任何命中都只是警告：这些连接会在该 Mac 升级后被阻断。而在 27.0 的 Mac 上，同样的命中会以错误的形式出现——那些连接此刻已经在失败了。

在一台 Tahoe Mac 上运行这项测试，你就能在任何东西真正出问题之前，拿到一份「将会失效」的清单。

一份服务器连接检查清单，大多数被标记为安全，其中一项被标记为需要关注

推广检查清单

对于即将迎来第一批 27.0 升级的机队，我们建议按以下顺序推进：

列出管理路径中的每一台服务器：MDM 服务器和签到 URL、自动化设备注册配置、应用清单和软件包托管服务器、DDM 资产 URL，以及任何会检查这些流量的代理或防火墙。
对每一台服务器运行 nscurl --ats-diagnostics，修复所有未通过默认安全连接检查的项目。
用 OpenSSL 3.x 检查 EMS，覆盖每一台终结 TLS 1.2 连接的服务器。
在一台 Tahoe 测试 Mac 上运行苹果的日志排查，走完从注册到更新的完整流程。
用声明式方式重建你的更新策略：为目标版本编写强制安装声明，用 softwareupdate.settings 管理延迟、自动操作和 Background Security Improvements。
切换报表，从 OSUpdateStatus 和 AvailableOSUpdates 迁移到声明式状态项。
检查你的自动化脚本，查找是否还在使用旧版命令名：ScheduleOSUpdate、ScheduleOSUpdateScan、AvailableOSUpdates、OSUpdateStatus。
告知服务台，基于节奏隐藏更新的机制在 27.0 上已经不复存在，并说明用户接下来会看到什么。
升级一个试点小组，在真实的 27.0 硬件上确认注册、应用安装和更新强制安装都能正常工作，之后再扩大范围。

常见问题排查

27.0 的 Mac 无视你设置的更新截止时间

问题：一台已升级到 Golden Gate 的 Mac，没有安装你的策略要求的次要版本更新。

解决方法：检查这条策略用的是哪种机制。如果是旧版 ScheduleOSUpdate 命令或 MDM 限制，它在 27.0 上已经不起作用了。改为下发一条 softwareupdate.enforcement.specific 声明；如果依然无法安装，就读取设备的 softwareupdate.failure-reason 状态。

新 Mac 的更新报表显示「unknown」

问题：你的补丁仪表盘对运行 27.0 的 Mac 不显示任何更新数据。

解决方法：这个仪表盘读取的是旧版查询响应，把它切换到声明式状态项 softwareupdate.install-state 和 softwareupdate.pending-version。

注册在 Tahoe 上正常、在 Golden Gate 上失败

问题：一台运行 27.0 的新 Mac 在自动化设备注册过程中失败，而配置相同的 Tahoe Mac 却能成功。

解决方法：在排除其他可能之前，先当作是 TLS 变更导致的。用 nscurl --ats-diagnostics 测试注册流程中的每一个 URL，并检查设备日志中来自 mdmclient、Setup Assistant 或 profiles 的 ATS 错误。

企业应用在 27.0 上无法安装

问题：从你自己的服务器分发的自定义应用安装失败。

解决方法：清单或软件包托管服务器很可能没有满足 TLS 要求。这通常是一台较旧的 Web 服务器，从未被纳入过 MDM 安全加固的范围。内容缓存服务器是豁免的，所以问题出在源站服务器上。

进行 TLS 检查的防火墙破坏了管理流量

问题：一切在企业网络之外都正常，一进入企业网络就出问题。

解决方法：进行检查的设备会用自己的证书和 TLS 配置重新签发连接，而这些配置现在同样必须满足 ATS 要求。要么升级它的配置，要么把你的管理主机和苹果的 MDM 端点从检查范围中排除。

常见问题

macOS 26 上旧版软件更新命令还能用吗？

可以。苹果的 schema 把它们标记为 26.0 弃用、27.0 移除，所以运行 Tahoe 的 Mac 仍然会遵守它们，而运行 27.0 的 Mac 不会。在过渡期间，建议用声明式方式定义策略，让所有 Mac 都得到一致的结果。

什么替代了推荐节奏设置？

在 macOS 上，没有直接的替代品。苹果的 schema 把声明式 RecommendedCadence 键标记为 macOS 不可用。请用延迟设置来隐藏版本，用强制安装声明来要求安装你想要的版本。

内容缓存服务器会受到 TLS 变更的影响吗？

不会。苹果把内容缓存服务器列为例外，「即便请求的是与应用安装或软件更新相关的资源」也是如此。SCEP 服务器同样豁免。

在任何 Mac 升级之前，我怎么知道哪些服务器会出问题？

在一台 Tahoe 测试 Mac 上安装苹果的 Network Diagnostics Logging 描述文件，运行你的工作流程，采集一份 sysdiagnose，再用苹果支持文章中的日志谓词进行搜索。在 26.x 上，违规会以警告形式出现，所以你能在它们真正造成问题之前就发现。

这对未受管理的 Mac 有影响吗？

软件更新方面的变化不会影响。TLS 规则同样覆盖所有 Mac 的软件更新和应用安装，但这些连接通常指向苹果自己的服务器，本就满足要求。你可以用 profiles status -type enrollment 检查一台 Mac 是否受管理——在未受管理的 Mac 上，两行结果都会显示「No」。

结语

macOS 27 完成了苹果自声明式管理出现以来一直在释放信号的一次转变。在 27.0 上，更新控制现在只能靠声明式方式完成；管理路径现在执行的传输安全要求，与任何现代应用连接别无二致。这两处改动都不涉及用户界面，所以一支机队完全可能在毫无察觉的情况下同时撞上它们——直到某个截止日期被错过，或某次注册失败。

两者都可以通过今天就能在 Tahoe 上完成的准备工作来避免。测试你的服务器，在一台 Mac 上运行苹果的日志排查，用声明式方式重建更新策略，并重新指向你的报表。在第一批 27.0 的 Mac 到来之前完成这些工作，接下来的升级就会是一件寻常事。

相关工具: macOS 版本追踪器 - 每个 macOS 版本的最新更新，以及它是否仍在接收安全更新，数据取自 Apple 的发布记录。