Los proyectos de la comunidad produjeron dos cambios concretos entre el 3 y el 10 de noviembre de 2026: CIPP-API amplió su manejo de aprobaciones multiadministrador de Intune, mientras que KyttoMCP publicó una versión de Windows con cambios relacionados con el reinicio y la administración de ventanas. Los repositorios de Evergreen también registraron actividad, aunque sus listados no identificaron versiones ni modificaciones específicas.

Para los administradores de TI, el tema práctico es la adopción controlada: la automatización de aprobaciones merece pruebas de flujo de trabajo, las correcciones de escritorio necesitan validación representativa de Windows y la actividad de un repositorio no debe confundirse con una versión documentada.

Windows

KyttoMCP 1.0.9.3-windows

El responsable heyitsjakub publicó la versión 1.0.9.3-windows de KyttoMCP el 7 de noviembre de 2026, según la página de versiones de GitHub del proyecto. La versión añadió una acción de Reiniciar ahora y corrigió una condición en la que una ventana maximizada cubría la barra de tareas de Windows.

Se trata de cambios acotados, pero ambos afectan al comportamiento visible para el operador. Un control de reinicio modifica lo que un administrador o usuario puede iniciar desde la aplicación, mientras que la corrección de la barra de tareas aborda la interacción con un elemento central del shell de Windows.

  • Versión: 1.0.9.3-windows
  • Responsable: heyitsjakub
  • Fecha de lanzamiento: 7 de noviembre de 2026
  • Licencia: No se indica en la información de la versión
  • Cambios: Se añadió una acción de Reiniciar ahora y se corrigió una ventana maximizada que cubría la barra de tareas

La acción Reiniciar ahora debe tratarse como un control operativo, no como una adición estética. Su equipo debe establecer quién debe usarla, qué trabajo podría interrumpirse y si el comportamiento de la aplicación coincide con los procedimientos de reinicio existentes antes de poner la versión a disposición de forma generalizada.

La corrección de la barra de tareas también necesita pruebas en las condiciones de escritorio que su organización utiliza realmente. Las notas de la versión identifican el síntoma corregido, pero no establecen cómo se comporta el cambio con todas las configuraciones de pantalla, ventana o sesión. Una prueba de inicio correcta no es suficiente. Valide la ruta de ventana maximizada que motivó la corrección.

La versión anterior del proyecto, del 5 de noviembre de 2026, modificó MCP Doctor para que dejara de recomendar servidores de referencia archivados y señalara esos servidores cuando ya estaban en uso, según el mismo historial de versiones de GitHub. Ese cambio proporciona a los administradores un segundo punto de validación al pasar entre las compilaciones de la semana: las recomendaciones y advertencias pueden diferir incluso cuando el flujo de trabajo circundante parece conocido.

No se trata de un cambio binario aislado. Es una secuencia breve de versiones que afecta tanto a las acciones de los usuarios como a la orientación de diagnóstico.

Qué significa esto para los administradores: Pruebe 1.0.9.3-windows como una actualización operativa completa. Confirme la nueva acción de reinicio, reproduzca el escenario de ventana maximizada y revise la salida de MCP Doctor en entornos que ya hagan referencia a un servidor archivado. Dado que la información de versión disponible no indica una licencia, resuelva las cuestiones de licencia antes de distribuirla, en lugar de asumir que la visibilidad del repositorio establece derechos de implementación.

Los administradores también deben registrar la compilación exacta evaluada. La cadena de versión incluye el sufijo de Windows, por lo que las notas de implementación, los resultados de pilotos y los registros de reversión deben conservar 1.0.9.3-windows en lugar de abreviarlo a una etiqueta menos precisa.

Intune

CIPP-API añade una ruta de reintento de aprobación

CIPP-API de Kelvin Tegelaar añadió New-CIPPIntuneApprovalRequest, mejoró el manejo de solicitudes de Graph para rechazos de aprobación multiadministrador de Intune e introdujo una tarea de reintento recurrente denominada Invoke-CIPPIntuneApprovalRetry, según el commit 2d42568d94d6bc5ebe8b9c2532e849fcef6e4e1b.

La tarea de reintento tiene como objetivo completar escrituras aprobadas. Esto es importante porque una aprobación y la escritura resultante son resultados operativos independientes: una solicitud puede alcanzar un estado aprobado sin que el cambio previsto se complete en el primer intento. La tarea recurrente añade un mecanismo para volver a abordar esa segunda etapa.

  • Responsable: Kelvin Tegelaar
  • Identificador del cambio: 2d42568d94d6bc5ebe8b9c2532e849fcef6e4e1b
  • Nueva función de solicitud: New-CIPPIntuneApprovalRequest
  • Nueva tarea de reintento: Invoke-CIPPIntuneApprovalRetry
  • Licencia: No se indica en la información del commit
  • Versión: No se indica en la información del commit

El manejo mejorado de los rechazos de aprobación merece la misma atención. Un rechazo no es simplemente una respuesta de API que se debe registrar e ignorar; es un resultado del flujo de trabajo que debe seguir siendo distinguible de un fallo transitorio, una solicitud aprobada pendiente de finalización o una escritura que finalmente tuvo éxito.

Por lo tanto, su plan de pruebas debe cubrir varios estados. Verifique la solicitud inicial, una ruta de rechazo, una ruta de aprobación y el comportamiento de la tarea de reintento recurrente cuando una escritura aprobada siga incompleta. Después, confirme que los operadores pueden distinguir esos resultados a partir de los registros e interfaces disponibles.

Quizá el cambio con mayores consecuencias sea la naturaleza recurrente de Invoke-CIPPIntuneApprovalRetry. La recurrencia puede mejorar la finalización del trabajo aprobado, pero también modifica el comportamiento ante fallos. Un intento único sin éxito se convierte en una acción que puede volver a intentarse.

No se trata simplemente de manejo de errores. Es un cambio en el ciclo de vida de una escritura administrativa.

Los detalles del commit establecen que la tarea de reintento existe para completar escrituras aprobadas, pero no indican un número de versión ni proporcionan una política de implementación completa para cada tenant. Su equipo debe establecer sus propios criterios de aceptación respecto a la ejecución repetida, la observabilidad y la reversión antes de depender de la nueva ruta.

Los administradores deben prestar especial atención al límite entre la aprobación humana y la finalización automatizada. La aprobación multiadministrador crea un punto de decisión intencional; la lógica de reintento debe preservar esa decisión en lugar de ocultar si una escritura posterior corresponde a la solicitud aprobada.

Qué significa esto para los administradores: Ejecute el flujo de trabajo de aprobación en un tenant no productivo o en un ámbito piloto antes de adoptar el commit. Capture qué aparece cuando se rechaza una solicitud, qué indica que una solicitud fue aprobada y cómo informa la tarea recurrente de una escritura completada o todavía incompleta. Fije el commit probado, ya que el origen no identifica una versión de lanzamiento para estos cambios.

Las licencias también siguen sin resolverse en la información del commit citada. Antes de que su organización empaquete, modifique o redistribuya componentes de CIPP-API, revise los términos actuales del repositorio del proyecto y haga que el responsable apropiado confirme que el uso previsto está permitido.

Evergreen muestra actividad en el repositorio

El listado de la organización EUCPilots registró actividad en el repositorio Evergreen el 8 de noviembre de 2026. El listado identifica la licencia del proyecto como MIT, pero no describe un cambio específico, una versión ni la versión más reciente.

  • Responsable: EUCPilots
  • Licencia: MIT
  • Actividad del repositorio: 8 de noviembre de 2026
  • Versión: No se indica
  • Cambio específico: No se indica

Esa distinción es importante. Una actualización del repositorio puede representar muchos tipos de actividad, y el listado por sí solo no establece que los administradores hayan recibido una nueva funcionalidad, corrección de errores, paquete o versión lista para producción.

Esto es evidencia de actividad, no evidencia de una versión.

Qué significa esto para los administradores: No inicie una implementación de Evergreen únicamente porque el repositorio muestre una actualización reciente. Revise el historial real del código fuente, identifique qué cambió, determine si existe un artefacto de versión y compare ese cambio con la revisión que ya está en evaluación. Si esas preguntas no pueden responderse, conserve la revisión actualmente probada.

La licencia MIT proporciona una base de licencia declarada, pero no sustituye la revisión técnica. Las licencias y la preparación operativa son controles independientes.

Evergreen Module sigue siendo relevante para canalizaciones de imágenes

El listado de la organización EUCPilots también registró actividad en el repositorio Evergreen Module el 9 de noviembre de 2026. El proyecto está asociado con la automatización de Intune y crea canalizaciones de compilación de imágenes de Windows utilizando versiones actuales de aplicaciones y URL de descarga, según el listado del repositorio.

El mismo listado identifica la licencia como MIT, pero no indica una versión más reciente ni explica qué cambió el 9 de noviembre.

  • Responsable: EUCPilots
  • Licencia: MIT
  • Actividad del repositorio: 9 de noviembre de 2026
  • Propósito: Crea canalizaciones de compilación de imágenes de Windows con versiones actuales de aplicaciones y URL de descarga
  • Versión: No se indica
  • Cambio específico: No se indica

Las canalizaciones de imágenes convierten la información de aplicaciones ascendentes en entradas de compilación descendentes. Esto hace que la revisión de cambios sea importante incluso cuando una actualización del repositorio parece rutinaria: un ajuste sin examinar puede afectar a lo que una canalización recupera o incorpora a una imagen.

El listado no establece que ese comportamiento haya cambiado esta semana. Sí establece suficiente actividad para justificar una inspección, no una adopción automática.

Qué significa esto para los administradores: Compare el estado del repositorio del 9 de noviembre con la revisión fijada en su flujo de trabajo de creación de imágenes. Revise cualquier diferencia antes de permitir que el módulo influya en una imagen nueva y verifique las versiones de aplicaciones y ubicaciones de descarga resultantes en una compilación desechable. Mantenga disponible la revisión conocida anterior hasta que el nuevo estado supere esa validación.

Evergreen Module y Evergreen no deben tratarse como intercambiables simplemente porque EUCPilots mantiene ambos y ambos utilizan la licencia MIT. Registre el repositorio y la revisión exactos que utiliza cada ruta de automatización. La precisión en este punto favorece compilaciones repetibles y decisiones de reversión más claras.

Pruébelo de forma segura

  1. Comience en un entorno controlado. Pruebe los estados de aprobación de CIPP-API en un tenant de laboratorio o en un ámbito piloto estrictamente limitado, y evalúe KyttoMCP en sistemas Windows representativos antes de una implementación más amplia.

  2. Lea el código fuente y confirme la licencia. Evergreen y Evergreen Module indican la licencia MIT, mientras que la información disponible del commit de CIPP-API y de la versión de KyttoMCP no indica licencias. Resuelva esas carencias antes de empaquetar o redistribuir.

  3. Fije la revisión exacta. Registre 1.0.9.3-windows para KyttoMCP y el commit 2d42568d94d6bc5ebe8b9c2532e849fcef6e4e1b para los cambios de CIPP-API. Para los proyectos Evergreen, capture la revisión precisa revisada en lugar de depender de una fecha de actividad del repositorio.

  4. Ejercite la ruta modificada. Active la acción de reinicio de KyttoMCP, reproduzca el escenario de ventana maximizada, pruebe los resultados de aprobación y rechazo de CIPP-API e inspeccione el comportamiento de reintento para una escritura aprobada que no se complete inmediatamente.

  5. Compruebe la evidencia de mantenimiento antes de depender de ella. Revise las notas de la versión, los cambios del código fuente, la actividad de incidencias y las opciones de reversión. La actividad reciente de un repositorio por sí sola no identifica qué cambió ni establece que esté listo para su entorno.

Las herramientas creadas por la comunidad pueden cubrir brechas operativas concretas, pero cada proyecto debe verificarse antes de implementarse. Su equipo debe establecer las licencias, probar la versión o el commit exactos, documentar el comportamiento esperado y conservar una ruta de reversión antes de incorporar cualquiera de estos cambios a los flujos de trabajo de producción.