El caso del dispositivo que se recupera solo
El panel de investigación
- La gestión declarativa de dispositivos (DDM) de Apple se extiende ahora al despliegue de aplicaciones, lo que permite a los dispositivos detectar y corregir por sí mismos las instalaciones fallidas sin que tenga que intervenir un técnico.
- En lugar de que un servidor consulte repetidamente el estado, el dispositivo compara su estado con su propio archivo de manifiesto e informa en cuanto detecta algún cambio.
- Los nuevos controles de aplicaciones gestionadas permiten a los administradores configurar actualizaciones automáticas, limitar las instalaciones a Wi-Fi o permitirlas mediante datos móviles, y bloquear u ocultar aplicaciones, todo desde el mismo motor de políticas que ya utilizan.
- Cuando «Actualización automática» se configura como «Siempre activado», prevalece sobre la configuración del propio dispositivo del usuario final, por lo que una preferencia personal no puede hacer que una aplicación se quede desactualizada.
- Estas funciones requieren que los dispositivos estén inscritos en DDM y ejecuten una versión 26 o posterior del sistema operativo; los dispositivos más antiguos seguirán funcionando exactamente como hasta ahora.
- Si una declaración DDM entra en conflicto con un comando MDM tradicional, la declaración DDM siempre prevalece.
Todos los administradores de TI se han encontrado alguna vez con un caso parecido. Se intenta desplegar una aplicación mediante una política y, en algún punto entre la orden y el dispositivo, algo sale mal. En algún momento del proceso se pierde la pista: se interrumpe la conexión, el dispositivo está ocupado y la instalación nunca llega a realizarse. No hay avisos, alertas ni señales de alarma. La aplicación simplemente no está en el dispositivo, que permanece sin cumplir la política asignada hasta que alguien se da cuenta. Puede que el usuario final abra un ticket o envíe un mensaje, o que un administrador de TI sobrecargado descubra que a parte de la flota le falta una aplicación crítica. Sin embargo, normalmente es el usuario quien lo detecta, por lo que el administrador de TI tiene que investigar a posteriori en la consola para averiguar qué ha ocurrido.
Multiplica esto por miles de dispositivos de la flota, con distintas versiones del sistema operativo y aplicaciones, y ya no tienes un misterio: tienes un problema serio de desviación respecto al estado esperado que obliga a revisar los dispositivos hasta dar con la causa. Es un problema que avanza poco a poco sin que nadie lo vea, hasta que los «detectives» de TI entran en acción para buscar al culpable y averiguar por qué las cosas no están «funcionando» como deberían. Esto no es una película de detectives: estamos en 2026 y los dispositivos no deberían necesitar que una persona detecte que algo va mal antes de poder corregirlo.
NinjaOne tiene algo nuevo. Ahora el dispositivo puede resolver su propio caso de forma proactiva. Ya está trabajando en ello
Una nueva forma de llevar la investigación
Para entender el cambio, veamos cómo funcionaba este proceso hasta ahora.
Apple creó la gestión declarativa de dispositivos (DDM) como una extensión del protocolo MDM existente, no como un sustituto. DDM complementa la gestión de dispositivos que NinjaOne ya ofrece, pero funciona de una forma muy distinta.
Antes, el «detective» era el servidor MDM. Enviaba un comando y después consultaba el dispositivo. Una y otra vez. Preguntando sin parar: «¿Se ha instalado? ¿Se ha instalado? ¿Cuál es el estado?». Este enfoque reactivo acaba generando un consumo elevado de ancho de banda cuando hay cientos de dispositivos. Es un proceso agotador y poco productivo, comprobación tras comprobación. Con DDM, el dispositivo se convierte en el detective. Compara su propio estado con un archivo de manifiesto para comprobar si coincide con el estado esperado. Si algo no cuadra, el dispositivo informa de inmediato al MDM a través de un canal de estado específico en cuanto detecta un cambio. Elemental, querido Watson.
En el caso de las aplicaciones, esto significa que el protocolo DDM de Apple se encarga de la distribución y la aplicación de las políticas para todas las aplicaciones definidas en una política de NinjaOne en dispositivos compatibles con DDM. Si falla la instalación de una aplicación, el dispositivo no espera. Se pone con el caso. El dispositivo reabre el expediente y vuelve a intentarlo por su cuenta. Y si un comando MDM tradicional y una declaración DDM dan instrucciones contradictorias, no hay duda de quién manda en la investigación: la declaración DDM prevalece siempre.
El gran avance del caso: controles de aplicaciones gestionadas
Toda buena historia de detectives necesita nuevas herramientas, y esta versión pone unas cuantas en manos de los administradores, entre ellas:
- Auto Update (actualización automática): mantiene las aplicaciones al día sin que un técnico tenga que enviar nuevas versiones. Si se configura como «Siempre activado», prevalece incluso sobre la configuración del propio dispositivo del usuario final, por lo que una preferencia personal no puede hacer que la aplicación se quede desactualizada.
- Instalaciones solo por wifi o permitidas mediante datos móviles ayudan a evitar costes inesperados por el consumo de datos móviles.
- Opciones de bloqueo u ocultación: permiten al administrador decidir cuánto control tienen los usuarios finales sobre las aplicaciones gestionadas.
El funcionamiento es sencillo. El administrador define la política y configura estas opciones. A partir de ahí, el dispositivo se encarga de alcanzar el estado deseado. Las instalaciones fallidas se vuelven a intentar automáticamente, las actualizaciones se aplican según lo programado y los dispositivos se mantienen en el estado esperado sin que nadie tenga que vigilarlos con lupa ni comprobar constantemente su estado. Si hubiera que resumir esta sección en una frase: el dispositivo se gestiona solo.
Una breve nota sobre los requisitos: estas funciones declarativas requieren que los dispositivos estén inscritos en DDM y ejecuten una versión 26 o posterior del sistema operativo. Los dispositivos con versiones anteriores siguen funcionando exactamente como hasta ahora, sin interrupciones; simplemente aún no disponen de esta nueva capacidad de corregir automáticamente los fallos.
Tres casos cerrados sin que intervenga un técnico
Caso 1: el ciclo de resincronización manual. Antes, los técnicos tenían que encargarse de toda la investigación. Detectar el dispositivo que no cumplía la política, averiguar por qué, resincronizarlo manualmente y esperar que se solucionara. Ahora el propio dispositivo detecta una instalación fallida y vuelve a intentarlo, sin necesidad de seguimiento ni intervención adicional. El veredicto: ya no hace falta resincronizar manualmente. Esto se aplica, de ahora en adelante, a las asignaciones de aplicaciones nuevas o modificadas. Las aplicaciones instaladas antes de activar DDM siguen necesitando una resincronización puntual de la política para pasar a gestionarse mediante DDM.
Caso 2: la aplicación que nunca se actualiza. El detective ya no tiene que acordarse ni comprobar nada: Auto Update mantiene los dispositivos en la versión más reciente como parte de la política. Esto reduce el tiempo durante el que un dispositivo ejecuta software desactualizado y potencialmente vulnerable, y también el número de tickets que preguntan: «¿Por qué sigue teniendo una versión antigua?». El veredicto: menos dispositivos vulnerables y menos tickets.
Caso 3: el MSP que gestiona una docena de «escenas del crimen» a la vez. Cada entorno de cliente tiene sus propias limitaciones de ancho de banda. Las instalaciones solo por Wi-Fi evitan consumos inesperados de datos móviles en los dispositivos con conexión móvil. Los reintentos automáticos ayudan a mantener un cumplimiento uniforme de las políticas en todos los clientes sin que los técnicos tengan que revisar las instalaciones fallidas una por una o sede por sede. El veredicto: cumplimiento uniforme de las políticas, sin seguimiento manual.
¿Cómo encaja todo esto en la investigación?
Estos controles se encuentran en el mismo motor de políticas que los administradores ya utilizan para el resto de la gestión de dispositivos Apple. No hay que aprender a utilizar una consola nueva ni nuevos flujos de trabajo. Es una pista más de hacia dónde avanza la gestión de dispositivos Apple en NinjaOne: hacia un modelo en el que los dispositivos investigan y resuelven cada vez más sus propios casos, mientras los técnicos dedican menos tiempo a buscar pistas sobre problemas que ya se han resuelto solos.
Caso cerrado (por ahora)
La gestión declarativa de dispositivos no se limita a enviar una aplicación a un dispositivo y esperar que todo salga bien. Le entrega al dispositivo una placa, un expediente y la autoridad para cerrar sus propias investigaciones, sin necesidad de pedir refuerzos.
El despliegue de aplicaciones es solo el primer expediente. Mantente al tanto: la gestión declarativa de dispositivos irá abriendo nuevos expedientes en más áreas de la gestión de dispositivos Apple.
La gestión declarativa de dispositivos está disponible para NinjaOne MDM con la versión 15.0.
