Diseño de grupos, asignaciones y ventanas de mantenimiento en Intune
Intune casi nunca te bloquea. Para prácticamente cualquier objetivo (llevar esta aplicación a aquellos portátiles, mantener esa política lejos de los kioscos) hay tres o cuatro caminos que funcionan todos el día que los montas. Unos te llevan diez minutos y otros una tarde.
Esa flexibilidad es la gran virtud del producto y su principal riesgo de diseño. Nada en la consola distingue el camino que seguirá teniendo sentido dentro de dos años del que se va acumulando en silencio hasta formar una estructura que ya no hay quien lea. El coste de elegir mal no aparece cuando lo construyes. Aparece el día que alguien pregunta por qué el PC de una sala de reuniones está recibiendo una política pensada para portátiles de empleado, y reconstruir la respuesta cuesta una mañana.
Microsoft publica buenas prácticas, y deberían ser el punto de partida. Pero en muchas decisiones de diseño del día a día la guía se queda corta de una respuesta única, porque la correcta depende de qué estés optimizando. Lo que sigue es el diseño con el que me he quedado, y de momento aguanta: qué estandarizar, qué método de segmentación va en cada sitio y cómo decidir cuándo se le permite a un cambio llegar a un dispositivo.
Estructura: cómo deberían construirse los grupos
Define la convención de nombres antes de crear el primer grupo. Leer el nombre de un grupo debería decirte exactamente qué asigna y a qué. Esto no es orden por el orden: es la decisión que hace asumibles todas las demás reglas, porque una estructura hecha de grupos de propósito único solo es navegable si los nombres cargan con el significado. Es también la única decisión de esta lista que se encarece cada semana que la aplazas.
Un solo tipo de destino por grupo: usuarios o dispositivos, nunca los dos. La guía de Microsoft es explícita en que los grupos que mezclan usuarios y dispositivos producen conflictos de política y comportamientos de despliegue impredecibles.
Los grupos de exclusión tienen que apuntar al mismo tipo que el grupo de inclusión. Esto no es una preferencia estilística: es un límite de soporte, y es la regla más importante de todo el artículo. Asignar a un grupo de dispositivos excluyendo un grupo de usuarios no está soportado: Intune no evalúa la relación entre un usuario y sus dispositivos, así que los equipos de los usuarios excluidos no quedan excluidos. Y no da ningún error. Simplemente no hace nada, en silencio, lo que significa que un administrador puede creer que una población está a salvo de una política cuando no lo está.
Evita el anidamiento. La pertenencia efectiva de un grupo padre cambia en silencio cuando alguien edita un hijo, y el administrador que después use ese padre para una asignación no recibe ninguna señal visible. Hay un segundo coste, menos evidente: cuando un grupo grande se anida dentro de uno que Intune usa para segmentar, Intune reprocesa todas esas pertenencias, y en un tenant grande un solo cambio de anidamiento hecho por un administrador del directorio puede retrasar el procesamiento de asignaciones en todo el entorno.
Crea los grupos por adelantado, como parte de la operación estándar de dar de alta una aplicación, una política o un script. No después, cuando los nombres se improvisan con prisa.
Un propósito por grupo, con una excepción deliberada: el grupo maestro que hay detrás de un perfil de inscripción sí carga legítimamente con la base de todo ese perfil, el equivalente a lo que era la imagen en la época de SCCM.
Segmentación: elige el mecanismo, no solo el grupo
Los grupos no son la única forma de acotar una asignación, y tratarlos como si lo fueran es la fuente más habitual de complejidad evitable.
Usa filtros de asignación para las propiedades simples del dispositivo. Si la segmentación depende del sistema operativo, el fabricante, el modelo, la propiedad o la categoría del dispositivo, un filtro hace el trabajo sin crear ningún grupo. Se evalúa en el momento de la asignación, así que no hay que esperar a ninguna sincronización de directorio, y no suma al recuento de grupos. La recomendación explícita de Microsoft es preferir filtros a grupos dinámicos de dispositivo siempre que ese grupo solo lo vaya a consumir Intune.
Usa los grupos virtuales integrados. No construyas tu propio equivalente de «todos los usuarios» o «todos los dispositivos»: los destinos integrados no requieren sincronización de directorio cuando se añade un dispositivo o un usuario.
Reserva los grupos dinámicos para lo que un filtro no sabe expresar, y escribe reglas eficientes. Evita memberOf en las reglas de pertenencia dinámica: si hay que segmentar dispositivos por su pertenencia a otra cosa, busca una propiedad directa (nombre del perfil de inscripción, categoría de dispositivo, fabricante) que exprese esa misma población.
Nunca uses un grupo dinámico de dispositivos como exclusión en un escenario sensible a la latencia. Este es el filo más afilado de todo el diseño. Un equipo se inscribe, Intune empieza a entregarle políticas de inmediato, y el cálculo del grupo dinámico que tenía que excluirlo todavía no ha terminado. Durante esa ventana, el dispositivo recibe exactamente la configuración que la exclusión existía para evitar. Es comportamiento documentado, no un defecto, y además es invisible después: cuando alguien va a investigarlo, la pertenencia al grupo ya es correcta y la evidencia ha desaparecido. Asigna a un grupo de usuarios o al All Devices integrado y afina con un filtro.
Reutilizar grupos frente a radio de impacto
Microsoft recomienda reutilizar grupos todo lo posible, y el razonamiento se sostiene: cada grupo y cada cambio de pertenencia es trabajo que Intune tiene que procesar, así que menos grupos significa una segmentación más rápida y más predecible.
Eso tira en dirección contraria a la regla de un propósito por grupo, y conviene decir claramente que aquí hay un compromiso real y no una regla con respuesta evidente.
Un grupo reutilizado significa que ajustar la asignación de una aplicación ajusta también, en silencio, la de cualquier otro objeto que estuviera apuntando al mismo grupo; y nada en la interfaz te enseña quiénes son esos otros consumidores. Los grupos de propósito único contienen el radio de impacto de un cambio, a cambio de más grupos y más trabajo de sincronización.
La salida práctica es reducir la frecuencia con la que aparece la pregunta. Casi toda la especificidad que empuja a la gente hacia un grupo por asignación cabe en un filtro, que no cuesta nada de sincronizar. Empieza por los filtros, guarda los grupos específicos para lo que de verdad los necesita, y trata «un propósito por grupo» como la primera regla a relajar si algún día la latencia de segmentación se convierte en tu limitación.
Ventanas de mantenimiento: cuándo se permite que aterrice un cambio
La estructura es la mitad del diseño. La otra mitad son los tiempos, y en el fondo es el mismo problema, porque un anillo de actualización es una asignación a un grupo. Cuando el modelo de grupos está bien, las ventanas de mantenimiento se pueden expresar. Cuando no lo está, cada cambio se convierte en una negociación.
Hay tres cosas que hay que decidir a conciencia y pronto: qué cambios son críticos y cuáles no, qué ventana le toca a cada clase de dispositivo y quién tiene derecho a aplazar.
Qué cambios son críticos. Un parche de seguridad y un driver no son el mismo riesgo.
Qué ventana tiene cada clase de dispositivo. La define cuándo no se usa, no el reloj.
Quién puede aplazar. El usuario en su portátil; nadie en el PC de un aula.
Define la ventana por cuándo el dispositivo no se usa
No por el reloj. «Parchear de madrugada» se da por respuesta universal, y no lo es.
En un equipo compartido de un aula o una sala de reuniones, el día es el riesgo y la noche está libre. Lo que toca ahí es un bloqueo duro durante el horario lectivo o laboral (sin actualizaciones, sin reinicios y sin notificaciones) con las actualizaciones de característica programadas a mano en los huecos del calendario de la organización. En un entorno docente, esos huecos son los periodos vacacionales, porque son las únicas semanas en que el aula está vacía de forma fiable.
En el portátil de una persona, el mismo razonamiento da la respuesta contraria. A las tres de la mañana el equipo está apagado dentro de una mochila, así que una ventana nocturna no alcanza a nadie. El trabajo lo hacen entonces el aplazamiento, una fecha límite y el consentimiento del propio usuario.
Mismo producto, mismos ajustes, configuración opuesta. Porque la pregunta no es «¿cuándo parcheamos?» sino «¿cuándo no se usa esta clase de dispositivo?».
No fuerces reinicios en dispositivos de usuario
Un dispositivo no debería reiniciarse fuera del horario acordado, ni sin el consentimiento del usuario, salvo que una política de seguridad lo exija de verdad. Y en ese caso debería ser una decisión que alguien firma, no un valor por defecto que se quedó activado.
Esto no es un argumento de comodidad. Un equipo que se reinicia para actualizarse en mitad de una presentación con un cliente cuesta más que la vulnerabilidad que cerraba, y el coste no se queda en esa hora: son los seis meses siguientes de esa persona descartando cualquier aviso de reinicio nada más verlo. Así es como un parque acaba con meses de retraso en parcheo mientras todas las políticas se leen como correctamente configuradas. Forzar reinicios pone la gráfica de cumplimiento en verde muy rápido y empeora la situación real.
En dispositivos compartidos, donde la máquina no es de nadie, el principio sobrevive en versión reducida: un reinicio programado de madrugada dentro de la ventana en la que el aula está vacía, con un aviso corto y cancelable para la noche en que no lo esté. No cuesta casi nada y garantiza que la automatización nunca pase por encima de alguien que está ahí sentado de verdad.
Silencia los avisos de actualización solo en dispositivos compartidos
En una máquina que está proyectando en un aula o una sala de reuniones, ocultar los avisos de actualización y reinicio es lo correcto: una interrupción ahí es una sala llena de gente mirando un cuadro de diálogo.
En el dispositivo de un usuario, ese mismo ajuste es un error, porque elimina el consentimiento del que depende la regla anterior. No puedes pedirle a la gente que elija su momento de reinicio mientras le ocultas que hay un reinicio pendiente.
Esa distinción solo se puede expresar si esas poblaciones son grupos separados con asignaciones separadas, que es la mitad estructural de este artículo llegando por el otro lado.
Clasifica el cambio y aplaza en consecuencia
Tratar todo cambio como igual de urgente es lo que hace que las ventanas de mantenimiento se derrumben. Un parche crítico de seguridad y una actualización de driver no son el mismo riesgo y no deberían viajar a la misma velocidad.
En la práctica: actualizaciones de seguridad en un anillo definido con aplazamientos medidos en días; actualizaciones de característica aplazadas un mes o más y pilotadas en un anillo al que la gente se apunta voluntariamente; actualizaciones de drivers bajo aprobación manual, porque un driver malo en un proyector o en una base de conexión deja una sala fuera de servicio de una forma que un parche de seguridad malo normalmente no; y actualizaciones de aplicaciones ancladas a un canal lento y estable en lugar de a lo que haya salido esta semana.
El equilibrio hay que decirlo en voz alta: un dispositivo parcheado y de bajo riesgo, y una persona que puede trabajar sin que la plataforma la interrumpa. Esos dos objetivos están en tensión real, y el diseño debería declarar cuál de los dos está sacrificando en cada caso en vez de fingir que van de la mano.
Por dónde empezar
Dedica la primera tarde a la convención de nombres, antes de crear un solo grupo.
Después: un tipo de destino por grupo, nunca mezclados. Exclusiones que coincidan con su inclusión, que esa es un límite de soporte y no una preferencia. Nada de anidamiento. Filtros de asignación para todo lo que sea una propiedad simple del dispositivo, grupos dinámicos solo para lo que un filtro no sabe expresar, y ningún grupo dinámico de dispositivos usado como exclusión donde el momento de la inscripción importe.
Antes de que salga el primer anillo de actualización, deja escrito qué cambios son críticos, qué ventana tiene cada clase de dispositivo y quién puede aplazar. Los procedimientos se escriben solos en cuanto existen esas tres respuestas. Sin ellas, cada despliegue se vuelve a discutir desde cero y el parque se va quedando atrás en silencio mientras todas las políticas se leen en verde.
El objetivo de todo esto es un tenant donde una petición nueva sea una asignación a un grupo que ya existe y que se llama de forma evidente, y no uno donde cada petición empiece por una investigación sobre qué hay montado. El día uno cuestan lo mismo, en el mes dieciocho ya no.