Un go/no-go para el siguiente paso del slider de co-management

El problema

En una migración a co-management y Windows 11, cada reunión de seguimiento pregunta lo mismo: cuántos equipos están de verdad co-gestionados, qué se rompe si pasamos un workload a Intune para todos y si la siguiente ola va a acabar a tiempo. Las respuestas están en dos consolas que no comparten informe.

Qué he hecho

• Una consulta SQL de solo lectura para MECM (vistas de informes: salud del cliente, build del SO, colecciones) y una exportación en PowerShell para Intune (managedDevices con configurationManagerClientEnabledFeatures).
• Un cruce por nombre de equipo con cinco estados: co-gestionado, solo MECM (sin inscribir), inscrito fuera de co-management, en MECM sin cliente y solo Intune.
• Para cada equipo co-gestionado, la autoridad por workload que espera el plan frente a la que informa Intune.
• El avance de cada ola de Windows 11 y el hardware que impide la actualización.
• gates.md: para cada workload en Pilot, GO o NO-GO frente a límites acordados en plan.json, listo para pegar en la petición de cambio.

Cómo está hecho

Python solo con la librería estándar. La demo es una empresa inventada con 260 equipos a mitad de migración; los gates dicen NO-GO porque solo el 91,9 % de los equipos está co-gestionado y un equipo del piloto no ha recogido el cambio. 14 tests y un playbook para usarlo junto al comité de cambios.

Qué aprendí

De la migración a Windows 11 que lideré: casi todo el esfuerzo no está en la actualización, sino en encontrar los equipos que no están donde dice el plan. Acordar los gates antes del CAB, y no durante, ahorra las discusiones más largas.

Siguientes pasos

• Ejecutar la consulta SQL de solo lectura contra la base de datos de tu sitio MECM y la exportación de Intune desde Graph.
• Escribir tus workloads, olas y gates en plan.json.
• Llevar gates.md a cada comité de cambios antes de mover el slider.

¿Quieres llevarlo a tu entorno o adaptarlo a tu caso? Escríbeme y lo vemos.