¶ Команды MDM и профили не выполняются
Эта страница поможет, если профиль не устанавливается или не удаляется, а MDM-команда (блокировка, обновление ОС, сведения об устройстве, установка приложения) не выполняется или завершается ошибкой. Относится к macOS, iOS и iPadOS. Если не работают политики, скрипты или терминал, см. страницу Агент.
MDM-команда доставляется так: Ринго отправляет push через Apple, устройство получает его и само обращается к /mdm/connect за командой (подробнее см. Как устроен Ринго → доставка MDM-команды). Сбой возможен на любом из трёх участков: от сервера до Apple, от Apple до устройства и от устройства до сервера.
¶ Три самые частые причины
- Команды не выполняются ни на одном устройстве. Скорее всего, истёк APNs-сертификат. Проверьте поле «Истекает» в разделе Настройки → Сертификат APNS и продлите сертификат кнопкой Renew (см. Шаг 2).
- Команды не выполняются на одном устройстве. Скорее всего, устройство выключено, не в сети или профиль MDM с него удалён. Сравните время «Был онлайн» с полем «Дата последней отправки push-нотификации» (см. Статус «В очереди»).
- Команда в статусе «Отложено». Чаще всего экран устройства заблокирован, и это не ошибка (см. Статус «Отложено»). Команда в статусе «Отправлено» без результата. Устройство потеряло сеть или WAF блокирует его ответ (см. Статус «Отправлено» без результата).
Если ни одна из причин не подходит, определите проблему по статусу команды.
¶ Определите проблему по статусу команды
Откройте карточку устройства, вкладку Управление → Команды. Статус команды указывает, на каком участке произошёл сбой:
| Статус | Что произошло | Где решение |
|---|---|---|
| В очереди у всех устройств | Push не отправляются. | Шаг 1, Шаг 2, Шаг 3 |
| В очереди у одного устройства | Устройство не обращается к серверу за командами. | Статус «В очереди» |
| Отложено | Устройство получило команду, но сейчас не может её выполнить. Обычно это не ошибка. | Статус «Отложено» |
| Отправлено, результата нет | Сервер выдал команду, ответ устройства не пришёл. | Статус «Отправлено» без результата |
| Ошибка | Устройство отказалось выполнить команду. Причина указана в тексте под «?». | Статус «Ошибка» |
| Отменено, хотя никто не отменял | Команду отменил сервер. | Статус «Отменено» |
| Выполнено, но настройка не действует | Устройство приняло команду, но настройка не применилась. | Статус «Выполнено», но настройка не действует |
Посмотрите также вкладку Информация в карточке устройства. Поле «Дата последней отправки push-нотификации» показывает, когда Ринго последний раз отправлял устройству push, а колонка «Был онлайн» в списке устройств — когда устройство последний раз обращалось к серверу.
Если push отправлен недавно, а устройство давно не выходило на связь, оно не получает push или не может подключиться к серверу (см. шаги 4 и 5).
¶ Шаг 1. Проблема у всех устройств или у одного
Откройте список команд ещё у двух-трёх устройств.
- Если команды не выполняются у всех начиная с определённого дня, причина на стороне сервера: APNs-сертификат (шаг 2), связь сервера с Apple (шаг 3) или доступность
/mdm/connect(шаг 5). Выясните, что изменилось в этот день. Изменения в самом Ринго, например загрузку нового APNs-сертификата, показывает Настройки → Аудит-лог. - Если команды не выполняются у одного устройства или у устройств одной сети, см. Статус «В очереди» и проверьте сеть этих устройств (шаг 4, шаг 5).
¶ Шаг 2. APNs-сертификат
Откройте Настройки → Сертификат APNS и посмотрите поле «Истекает». Если сертификат истёк, push не уходят ни на одно устройство. Чтобы продлить сертификат, на identity.apple.com нажмите Renew напротив текущего сертификата, затем загрузите новый файл .pem в Ринго вместе с ключом, который составляет с ним пару (как проверить — ниже).
¶ Сертификат создан заново, а не продлён
Если вместо Renew нажать Create a Certificate, Apple выдаст сертификат с новым идентификатором (topic). При загрузке такого сертификата Ринго предупреждает: «Идентификатор нового сертификата отличается от текущего. После загрузки устройства потеряют управление. Убедитесь, что вы загружаете правильный сертификат». Устройства, зарегистрированные со старым сертификатом, ожидают push по старому идентификатору и не получат ни одного.
Признак: после загрузки нового сертификата команды перестали выполняться на всех ранее зарегистрированных устройствах, а новые устройства регистрируются и работают.
Чтобы проверить, сравните поле «Идентификатор» на странице сертификата с идентификатором, на который подписано устройство (на Mac его показывает apsctl status, см. Диагностика на устройстве → доставка push), или с файлом старого сертификата:
openssl x509 -in старый.pem -noout -subject # UID=com.apple.mgmt.External.…
Если идентификаторы различаются, загружен новый сертификат. Если старый сертификат ещё действует, верните его и продлите именно его кнопкой Renew. Если старый сертификат уже истёк, устройства придётся зарегистрировать заново.
¶ Сертификат и ключ из разных пар
Сертификат от Apple и ключ от поддержки Ринго должны составлять пару. Чтобы проверить, сравните хеши:
openssl x509 -in cert.pem -noout -modulus | openssl md5
openssl rsa -in key.key -noout -modulus | openssl md5
Если хеши различаются, загружен не тот ключ.
¶ Шаг 3. Сервер отправляет push в Apple
Push отправляет backend Ринго по HTTP/2 на api.push.apple.com:443. Порт 2197 не используется. Выполните на сервере Ринго:
curl -s --http2 -X POST https://api.push.apple.com/3/device/0 -w ' %{http_code}\n'
Ожидаемый ответ — {"reason":"MissingProviderToken"} 403. Если ответ другой:
| Результат | Причина | Решение |
|---|---|---|
| Таймаут | Исходящий трафик на порт 443 к 17.0.0.0/8 закрыт. |
Откройте доступ на межсетевом экране, по возможности по имени api.push.apple.com. |
| Ответ не от Apple или ошибка сертификата | HTTPS-прокси или SSL-inspection. | Исключите *.push.apple.com из инспекции или настройте исходящий прокси (см. Сеть → от сервера до Apple). |
| С хоста проверка проходит, а push не уходят | Хост выходит в интернет через прокси, а контейнер — нет. | Задайте APPLE_PROXY_URL для backend. Как это сделать и как проверить из контейнера, см. Сеть → от сервера до Apple. |
Ошибки отправки push записываются в лог backend:
docker logs roll-deploy-backend --since 2h 2>&1 | grep -E 'push notification|push token|blank APNS|Apple proxy|unregistered'
| Запись в логе | Значение |
|---|---|
Failed to send mdm push notification for device with udid '…': … getaddrinfo EAI_AGAIN api.push.apple.com |
Контейнер не может разрешить имя Apple: проблема с DNS сервера или Docker. |
То же с ETIMEDOUT, ECONNREFUSED, ECONNRESET |
Исходящее соединение с Apple на порт 443 закрыто или разрывается межсетевым экраном либо DPI. |
То же с ssl/tls alert certificate expired |
Срок действия APNs-сертификата истёк, Apple не принимает соединение. Push не уходят ни на одно устройство. Продлите сертификат (шаг 2). |
То же с [object Object] |
Apple отклонил push: сертификат APNs недействителен или идентификатор не совпадает. Причина в лог не записывается; проверьте сертификат (шаг 2). |
APNS reported unregistered push token for udid '…', marking device as not enrolled |
Push-токен устройства больше не действует (устройство стёрто или профиль удалён). Ринго снял устройство с учёта и отменил его команды (см. Статус «Отменено»). |
Failed to send blank APNS push for udid '…' |
Не отправлен пустой push, запрошенный кнопкой «Отправка пустого Push». |
Apple proxy CONNECT api.push.apple.com:443 failed: HTTP/1.1 407 … или … timed out |
Исходящий прокси отказал в соединении или недоступен. |
triggerQueue, missing mdm push token for udid '…' (каждые 30 мин) |
У устройства нет push-токена, push ему не отправляются (см. Статус «В очереди»). |
Успешная отправка push в лог не записывается. Признак доставки — следующая запись от устройства: Emit event (mdm.event) with data: [udid: …; … topic mdm.Connect; status: Idle].
Если ошибок отправки в логе нет, а команды не выполняются, push уходят, и причину нужно искать на стороне устройства (шаги 4 и 5).
¶ Шаг 4. Устройство получает push
Устройство поддерживает постоянное соединение с Apple по TCP-порту 5223, а если он недоступен — по порту 443 (на iOS только в Wi-Fi). Без этого соединения push не доходят, и команды остаются в статусе «В очереди», пока устройство само не обратится к серверу.
Выполните из сети устройства:
nc -vz -G 5 courier.push.apple.com 5223 # macOS (на Linux вместо -G 5 используйте -w 5)
Точнее всего доставку push проверить на самом Mac. Нажмите в карточке устройства «Отправка пустого Push», затем посмотрите время последнего полученного push:
sudo /System/Library/PrivateFrameworks/ApplePushService.framework/apsctl status | grep -A40 'mdmclient.daemon.push.production' | grep -E 'topic:|last incoming push'
Если время изменилось на текущее, push дошёл; переходите к шагу 5. Если время не изменилось, проверьте сеть до Apple (порты 5223 и 443, SSL-inspection; см. Сеть → от устройств до Apple) и совпадение идентификатора устройства с полем «Идентификатор» сертификата (шаг 2). Подробнее см. Диагностика на устройстве → доставка push.
¶ Шаг 5. Устройство подключается к серверу
Получив push, устройство должно само обратиться к https://<домен>/mdm/connect. Выполните из сети устройства:
curl -s -X PUT -w '\n%{http_code}\n' https://<домен>/mdm/connect
Ожидаемый ответ — код 400 и {"message":"Отсутствует тело mdm запроса",…}: пустой запрос дошёл до Ринго. Если вы получили 403, 404, 000 или HTML-страницу вместо JSON, запрос блокирует прокси, ACL, DNS или WAF (см. Сеть → адреса).
Самое надёжное доказательство — журнал Mac: в нём записан код ответа сервера на каждый запрос (Received HTTP response (код), см. Диагностика на устройстве → ответы сервера).
¶ Статус «В очереди»
Устройство ни разу не забрало команду, хотя на других устройствах команды выполняются. Возможные причины, от частых к редким:
- Устройство выключено, находится в режиме сна без сети или не подключено к сети. Проверьте «Был онлайн» в списке устройств. Никаких действий не требуется: команда будет выполнена, когда устройство подключится.
- Истекает сертификат устройства. Срок — один год с регистрации, дата указана в поле «Сертификат энролл профиля истечет» в карточке устройства. До этой даты отправьте команду «Обновить профиль MDM»: устройство получит новый сертификат на год.
- Пользователь удалил профиль MDM, а сообщение
CheckOutне дошло до сервера. Ринго считает устройство управляемым, но устройство больше не обращается к серверу. Проверьте профиль на Mac: Системные настройки → Основные → Управление устройством. Если профиля нет, удалите устройство из Ринго и зарегистрируйте заново. - В сети устройства закрыт доступ к APNs (порты 5223 и 443 к
17.0.0.0/8). См. шаг 4. - У устройства нет push-токена. Ринго ни разу не получил сообщение
TokenUpdate: регистрация прервалась или WAF блокирует/mdm/checkin. Такому устройству push не отправляются. Признак — запись в логе backend каждые 30 минут:triggerQueue, missing mdm push token for udid '<UDID>'. Восстановите доступ к/mdm/checkin, затем зарегистрируйте устройство заново.
¶ Статус «Отложено»
Устройство ответило NotNow: оно получило команду, но сейчас не может её выполнить. Чаще всего экран заблокирован, а команде нужен доступ к связке ключей (например, профиль с сертификатами или паролем Wi-Fi).
Это не ошибка: устройство запросит команду снова, когда условия изменятся. Если разблокировать устройство, команды начнут выполняться. Ринго повторяет отложенную команду с нарастающим интервалом (от 5 с до 10 мин) и в это время выдаёт устройству остальные команды. Статус «Отложено» сохраняется и при повторных выдачах, пока команда не будет выполнена.
Если команда остаётся в статусе «Отложено» несколько дней, выясните, почему устройство не может её выполнить. После 50 ответов NotNow Ринго отменяет команду автоматически (см. Статус «Отменено»).
¶ Статус «Отправлено» без результата
Ринго выдал команду в ответе на /mdm/connect, но ответ устройства (Acknowledged или Error) не пришёл. При следующем подключении устройства Ринго выдаст команду повторно. Возможные причины:
- Устройство потеряло сеть во время выполнения команды, например крышку ноутбука закрыли или пропал Wi-Fi. Проверьте, есть ли более поздние команды в статусе «Выполнено».
- WAF или прокси блокирует ответ устройства. Ответы на
ProfileList,CertificateList,InstalledApplicationListи списки обновлений ОС — это большие plist. Найдите в логе WAF или nginx за время отправки команды запросPUT /mdm/connectс кодом 403, 406 или 413. Подробнее см. Сеть → WAF.
Как определить причину. Если в журнале Mac есть Received HTTP response (403) или (413), запрос блокирует WAF или прокси (см. Диагностика на устройстве → ответы сервера). Если запрос устройства есть в логе nginx, но отсутствует в логе backend, его блокирует WAF. Если запроса нет ни в одном логе, устройство не подключалось (причина 1).
¶ Статус «Ошибка»
Устройство получило команду и отказалось её выполнить. Причина не в сети. Наведите указатель на значок «?» рядом со статусом, чтобы прочитать текст ошибки.
Ошибки, встречающиеся на практике:
| Текст ошибки (домен, код) | Команда | Причина | Решение |
|---|---|---|---|
«В полезной нагрузке «…» отсутствует обязательный ключ «Password».» (ConfigProfileUtil, -1) |
Установка профиля | В профиле есть сертификат PKCS #12 (com.apple.security.pkcs12) без пароля. |
Укажите пароль сертификата в профиле и установите профиль заново. |
«Не удается расшифровать зашифрованный профиль.» (CPProfile, -104) |
Установка профиля, «Обновить профиль MDM» | Профиль зашифрован для сертификата устройства, который к моменту доставки уже заменён. Так бывает, если команду «Обновить профиль MDM» отправили повторно, не дождавшись выполнения первой. | Если первая команда выполнена, действий не требуется. Иначе отправьте «Обновить профиль MDM» один раз и дождитесь результата. |
«Устройство не является контролируемым. Перезагрузка недоступна» (MDMErrorDomain, 12021) |
Перезагрузка и другие команды для контролируемых устройств | Команда доступна только для контролируемых (supervised) устройств. | Регистрируйте такие устройства через ADE или Apple Configurator. На неконтролируемых устройствах команда недоступна. |
««…» не является действительным типом запроса.» (MDMErrorDomain, 12021), например для ActivationLockBypassCode |
Любая | Команда не поддерживается этой ОС или типом регистрации. | Не отправляйте команду на такие устройства. |
MCMDMErrorDomain, 12085 |
Получение кода обхода блокировки | На устройстве нет кода обхода Activation Lock, например функция «Локатор» не включалась. | Для устройств без Activation Lock действий не требуется. |
Подробности ищите в логе backend по UDID и времени (см. Логи), а на Mac — в журнале, строка [ERROR] … [ErrorChain.0] (<команда>) [<домен>:<код>] (см. Диагностика на устройстве).
¶ Статус «Отменено»
Если никто из администраторов не отменял команду (это можно проверить в разделе Настройки → Аудит-лог), её отменил сервер:
- Все невыполненные команды устройства отменены одновременно, а в карточке указано «Пользователь удалил MDM профиль: Да». Apple сообщила, что push-токен устройства недействителен: устройство стёрто, переустановлено или профиль MDM удалён. В логе backend есть запись
APNS reported unregistered push token for udid '…'. Зарегистрируйте устройство заново. - Отменена одна команда, которая долго была в статусе «Отложено». Устройство 50 раз ответило
NotNow. В логе backend есть записьApple MDM command auto-cancelled [Type: …; UDID: …; NotNow count: 50]. Выясните, почему устройство не может выполнить команду (например, экран заблокирован), и отправьте её снова. - Отменены все невыполненные команды после повторной регистрации. Устройство зарегистрировали профилем заново (не командой «Обновить профиль MDM»): сервер отменяет его прежние команды и ставит команды заново. Действий не требуется.
- Отменены все невыполненные команды Mac, а в карточке указано «Пользователь удалил MDM профиль: Да». Агент сообщил, что профиля MDM на Mac нет. Зарегистрируйте Mac заново.
- Отменена команда обновления агента. У этой команды собственный срок действия (24 часа) и собственный порог
NotNow. Агент обновится при следующей попытке.
¶ Удаление профиля повторяется
Когда устройство выходит из области действия профиля, Ринго ставит команду RemoveProfile и отмечает профиль как ожидающий удаления. Неудавшиеся удаления сервер повторяет каждые 30 минут. Если удаление каждый раз завершается ошибкой, в списке команд накапливаются одинаковые команды «Удаление профиля».
Прочитайте текст ошибки удаления (под «?») и устраните причину: например, профиль уже удалён вручную или защищён от удаления. Затем отмените лишние команды в очереди.
¶ Статусы профиля на устройстве
У профиля конфигурации собственные статусы, отдельные от статусов команд. Их два набора: результат на каждом устройстве — во вкладке Журналы профиля, и состояние самого профиля в Ринго — в колонке «Статус» списка Профили.
| Где | Статус | Значение |
|---|---|---|
| Профиль → Журналы | В ожидании | Команда установки поставлена, результата ещё нет. Статус команды смотрите на вкладке Управление → Команды. |
| Выполнено / Не удалось | Устройство установило профиль или отказалось. Текст ошибки — у команды «Установка профиля» под «?». | |
| Ожидает удаления | Устройство вышло из области действия профиля, команда удаления поставлена. | |
| Удалён / Ошибка удаления | Устройство удалило профиль или отказалось. Неудачные удаления сервер повторяет каждые 30 минут. | |
| Список Профили, колонка «Статус» | Добавлен | Профиль действует и устанавливается на устройства в области действия. |
| Ожидает удаления | Профиль удалён в Ринго, устройствам отправлены команды удаления, не все устройства их выполнили. | |
| Удалён | Профиль снят со всех устройств. Повторное удаление стирает его из Ринго. |
Журнал хранит историю: на каждую установку в нём две строки, сначала «В ожидании», затем результат. Колонки «Выполнено», «В ожидании» и «Не удалось» в списке Профили показывают число устройств. Во вкладке Управление → Профили карточки устройства статусов нет, там только названия профилей.
Если профиль долго остаётся в статусе «В ожидании» или «Ожидает удаления», не выполняется сама MDM-команда. Определите причину по её статусу (см. Определите проблему по статусу команды).
¶ Статус «Выполнено», но настройка не действует
Устройство приняло команду, профиль установлен, но настройка не действует. Возможные причины:
- Конфликт профилей. Два профиля задают одну настройку по-разному, и результат непредсказуем. На macOS проверьте все профили устройства командой
sudo profiles show -type configuration. - Настройка вступает в силу после перезагрузки или повторного входа пользователя.
- Настройка не поддерживается этой версией ОС. Устройство принимает профиль, но игнорирует ключ.
¶ Редкие причины
- Очередь перегружена. По системным требованиям Ринго одновременно доставляет около 200 MDM-команд, остальные ожидают. Массовая отправка на тысячи устройств занимает несколько часов.
- Команды появляются в 03:00 и 15:00 по Москве. Это задания по расписанию, которые выполняются в 00:00 и 12:00 UTC (см. Как устроен Ринго → расписание), а не действия администратора.
- Два сервера используют один APNs-сертификат. Push доходит, но устройство обращается к тому серверу, который указан в его профиле. Каждому серверу нужен собственный сертификат.
- Домен Ринго изменён. Устройства обращаются к адресу из своего enroll-профиля, то есть к старому. См. Сервер → смена домена.
- Устройство зарегистрировано в другом MDM и не удалено из него. На iOS может быть только один профиль MDM.
¶ Если проблема не решена
Обратитесь в техническую поддержку (см. Обращение в поддержку). Для проблем с командами приложите: снимок экрана со списком команд устройства, UDID, время отправки команды, лог backend за этот час, журнал устройства (как его собрать, см. Диагностика на устройстве → сбор данных) и результаты проверок из шагов 3–5, выполненных из сети устройства.
Проверено на Ринго 3.0.5, октябрь 2026. Тексты ошибок — Справочник ошибок, термины — Термины.