Un inventario de dispositivos fiable: un endpoint, varios objetos, tres automatizaciones

Hay una pregunta que sale siempre en gestión de dispositivos, sobre todo cuando se espera que Intune alimente un inventario fiable: ¿por qué lo que enseña la consola nunca acaba de coincidir con lo que hay encima de las mesas? Microsoft va integrando piezas de la respuesta de forma nativa, poco a poco, pero buena parte sigue teniendo que automatizarla quien lleva la plataforma.

El punto de partida es un concepto con el que conviene ser pedante. Un dispositivo (un endpoint; de aquí en adelante, un objeto) puede existir en más de un sitio a la vez, y esos son objetos distintos:

Registrado en Entra ID. Alguien usó su cuenta corporativa en ese equipo para llegar a un recurso de empresa: inició sesión en Outlook, en OneDrive, en cualquier aplicación de Microsoft 365. Solo con eso ya existe un objeto en el directorio. Normalmente no es un dispositivo gestionado.
En Entra ID e inscrito en Intune. Ahora hay dos objetos que se sincronizan entre sí, pero siguen siendo dos objetos con dos trabajos distintos. Entra ID guarda la identidad: ahí es donde el objeto lleva sus pertenencias a grupos. Intune guarda la gestión: ahí es donde el objeto vive el día a día y donde los grupos se asignan a políticas, scripts y aplicaciones.

Ten presente esa separación y los modos de fallo se vuelven predecibles.

El caso que rompe el inventario

Reinstala Windows en una máquina a mano. Los objetos de Entra ID y de Intune sobreviven los dos a la reinstalación. Si el equipo se vuelve a inscribir, los objetos viejos deberían borrarse de los dos sitios, y normalmente no lo hace nadie.

Peor todavía: si el dispositivo perdió la confianza con Intune por lo que sea y se reinscribe, Intune crea un objeto nuevo. A partir de ahí, el mismo endpoint físico aparece dos o tres veces en la consola. Todos los recuentos están mal, todos los porcentajes de cumplimiento salen diluidos por fantasmas, y cualquier asignación dirigida a «todos los dispositivos» está apuntando a máquinas que ya no existen.

Tres automatizaciones que lo mantienen honesto

La rutina

Deduplicar por número de serie. Una tarea programada agrupa los objetos de Intune por número de serie y borra todos menos el que tenga la fecha de inscripción más reciente. El número de serie es la única identidad que sobrevive a una reinstalación; la fecha de inscripción es la que dice cuál es el objeto vivo.
Limpiar los dispositivos obsoletos con una cadencia fija. Se eliminan los objetos sin check-in ni inicios de sesión más allá de un umbral. 90 días es una definición razonable de obsoleto, y cualquier umbral más corto conviene rechazarlo, porque las ausencias normales (vacaciones, bajas) generan falsos positivos. La mitad de Intune está en Invoke-IntuneStaleDeviceCleanup.ps1, que por defecto solo informa y que separa retirar de borrar, porque no tienen el mismo radio de impacto ni de lejos. Y hay una cosa que va antes, siempre: copiar las claves de recuperación de BitLocker de todos los dispositivos afectados, porque borrar el objeto de Entra borra las claves guardadas en él, y el día que alguien necesite esa clave no es el día de enterarse de esto.
Alinear el usuario principal automáticamente. Según cómo se haya inscrito un equipo, el usuario principal suele estar mal: las inscripciones hechas con una cuenta de servicio, o por un técnico que se saltó el paso manual, dejan el dispositivo asignado a nadie o a quien no toca. El arreglo tiene dos mitades. Get-IntuneDeviceUserDrift.ps1 lee, para cada dispositivo, el último usuario que inició sesión, un dato que solo se expone a través de Microsoft Graph beta, así que esta pieza vive en el endpoint beta hasta que Microsoft lo promocione. Una Logic App lo ejecuta a diario y añade el resultado como una columna en una hoja de Excel, guardando tres columnas como mucho: hoy y los dos días anteriores. Cuando las tres columnas coinciden en un mismo usuario y ese usuario no es el usuario principal actual, la asignación se corrige con Set-IntuneDevicePrimaryUser.ps1, que también informa sin -Execute, como todo lo demás. Los tres días consistentes son la salvaguarda: un inicio de sesión suelto de un compañero o de un técnico no puede reasignar una máquina.

Qué guardar antes de borrar

Dos de las tres automatizaciones borran cosas, y en un directorio los borrados no tienen vuelta atrás. Mi recomendación es acompañarlas de una capa de almacenamiento pequeña (una Logic App o un runbook de Azure Automation escribiendo en blob storage) que guarde tres cosas:

Las claves de recuperación de BitLocker de todos los dispositivos afectados, si no están ya custodiadas en otro sitio. Esto es el prerrequisito de la limpieza de obsoletos, no un extra opcional.
Un registro mínimo de cada dispositivo eliminado: usuario si lo hay, número de serie si lo hay, cuándo y por qué. No el objeto entero: solo lo justo para poder responder meses después a «¿qué pasó con esta máquina?» sin guardar datos personales que ya no necesitas.
Una exportación periódica de la configuración de Intune: políticas, perfiles y asignaciones. Para copia de seguridad y restauración, el módulo de la comunidad que usé en producción durante años es IntuneBackupAndRestore, de John Seerden; que quede dicho. Sus dependencias se han retirado después, así que comprueba que sigue funcionando con tus versiones de módulos antes de fiarte. La idea es la misma en cualquier caso: una exportación fechada, programada y guardada fuera del tenant.

Esta última es la que se gana el sueldo el día que pregunta un auditor. «¿Puede enseñarme la configuración tal y como estaba, y demostrarme que podría recuperarla?» es pregunta estándar en una auditoría de seguridad (me la hicieron en una certificación ISO 27001 en la que participé) y una exportación fechada en blob storage es la diferencia entre una respuesta y una acción pendiente.

El usuario principal importa más de lo que parece: de él dependen el autoservicio del Portal de empresa, la resolución de políticas basadas en usuario y todos los informes que responden a «¿de quién es esta máquina?». Un inventario con el usuario principal mal puesto es un inventario incapaz de responder a la pregunta que más veces le van a hacer.