Cuando una actualización de Windows desactiva sus robots de UiPath: la trampa del Patch Tuesday

Una actualización de Windows puede desactivar sus robots de UiPath durante la noche sin que nadie se dé cuenta. Los robots sin supervisión funcionan en las horas en que nadie está en la oficina. Exactamente en esta ventana es donde la mayoría de las organizaciones también programan los ciclos de mantenimiento para los parches del sistema operativo. Por la mañana no hay ningún error, simplemente no hay resultado.

¿Por qué una actualización de Windows desactiva los robots sin supervisión?

Un robot sin supervisión necesita tres cosas, y una actualización puede cambiar las tres: una sesión de Windows activa, una interfaz sin cambios de la aplicación objetivo y una máquina accesible.

El reinicio es la parte obvia. La parte menos obvia es el inicio de sesión después. UiPath documenta varias políticas de Windows para escenarios sin supervisión que previenen el inicio automático de sesión. La política „Display information about previous logons during user logon“ genera una ventana emergente de seguridad al iniciar sesión e impide que el robot falle con el código de error 0x80070520; debe estar configurada en Disabled . También „Sign-in and lock last interactive user automatically after a restart“ interfiere con la creación de sesión y no debe estar configurada ni deshabilitada (Fuente: UiPath Robot, Session troubleshooting).

¿Cuándo llegan las actualizaciones? El ritmo de Microsoft en detalle

Microsoft publica las actualizaciones de seguridad mensuales para Windows el segundo martes de cada mes, generalmente a las 10:00 a.m. Hora del Pacífico. Quien solo conoce esta fecha conoce solo dos tercios del ciclo.

Según la propia descripción de Microsoft del ciclo de lanzamiento de actualizaciones, hay tres desencadenantes relevantes para reinicios no planificados (Fuente: Microsoft Learn, Update release cycle for Windows clients):

• Actualización de seguridad mensual: segundo martes del mes, acumulativa, clasificada como obligatoria por la mayoría de las organizaciones.
• Actualización de vista previa opcional: cuarto martes del mes, no relevante para la seguridad, sirve para la validación temprana de la próxima actualización de seguridad.
• Lanzamiento fuera de banda: según sea necesario, sin fecha fija, cuando es necesario cerrar una vulnerabilidad aguda.

Un cronograma que solo bloquea el segundo martes no cubre el cuarto martes ni los lanzamientos fuera de banda.

¿Por qué se rompen los selectores después de una actualización?

Los selectores identifican un elemento de interfaz por sus propiedades en el árbol de ventanas. Si una actualización cambia estas propiedades, el robot ya no encuentra el elemento, aunque aparezca sin cambios para un humano.

UiPath enumera varias causas en la solución de problemas de selectores, tres de las cuales están directamente relacionadas con actualizaciones (Fuente: UiPath, Troubleshooting selectors):

• Selectores rotos después de actualizaciones del navegador: las actualizaciones del navegador cambian la estructura de la página renderizada. Se recomienda actualizar los paquetes de Actividades.
• Cambios en la interfaz de la aplicación objetivo: una actualización de características de la aplicación empresarial desplaza nodos o atributos. La solución es nodos de selector adaptados u Objetivo Unificado con respaldo de visión por computadora.
• Diferencias en el entorno: las pruebas y la producción se ejecutan con diferente escala. UiPath recomienda consistentemente escalado del 100 por ciento en todos los entornos.

Los selectores robustos no son opcional, sino el seguro más económico contra días de parches. Caracteres comodín para partes dinámicas, atributos estables como aaname o id en lugar de índices de posición, y anclajes en lugar de rutas rígidas. El mismo principio se aplica entre herramientas, lo hemos descrito con más detalle para la página de Microsoft en selectores robustos y tiempos de espera en Power Automate Desktop.

¿Cómo superpone las ventanas de actualización y el cronograma del robot?

Las ventanas de actualización y el cronograma del robot no deben superponerse, y la actualización debe ejecutarse primero. Un robot que se inicia a las 02:00 mientras el parche se reinicia a las 02:30 pierde su ejecución en medio de la transacción.

Microsoft recomienda para máquinas virtuales un plan de parches escalonado que se puede transferir casi sin cambios a máquinas robot: desarrollo el segundo martes, pruebas el segundo miércoles, producción solo el segundo sábado o el domingo siguiente (Fuente: Microsoft Learn, Scalable Windows virtual machine patch management). Los días intermedios son la ventana de validación.

En la práctica esto significa: desactivar o posponer los disparadores para la noche del parche antes, colocar el reinicio en una ventana sin trabajos en ejecución e iniciar un pequeño proceso de verificación antes de la primera ejecución productiva.

¿Cómo se da cuenta de que un robot está inactivo antes de que el cliente lo note?

El Orchestrator reporta un robot como Unresponsive si el robot y el Orchestrator no se han comunicado en los últimos dos minutos (Fuente: UiPath Orchestrator, Robot Statuses). Esta señal está ahí, solo necesita llegar a alguien.

El Orchestrator conoce los niveles de gravedad Info, Success, Warn, Error y Fatal y entrega mensajes a través de cuatro caminos: el banner en la interfaz, el panel Alertas, la página Alertas y resúmenes de correo electrónico. Lo importante para las ejecuciones nocturnas es la diferencia entre los dos formatos de correo: el resumen de diez minutos contiene exclusivamente alarmas de los niveles Fatal y Error, el resumen diario recopila todos los eventos suscritos a partir de las 10:00 a.m. hora local (Fuente: UiPath Orchestrator, Alerts).

Quien solo se ha suscrito al resumen diario se entera de una falla a las 02:00 a.m. a más tardar por la mañana. Para ejecuciones nocturnas, el resumen de diez minutos es la opción correcta, complementado con un control funcional: un trabajo técnicamente exitoso que no ha movido ningún registro es el error que ninguna alarma del sistema encuentra.

En nuestros proyectos de automatización, exactamente esa es la brecha más común: el monitoreo técnico está en su lugar, pero falta el control funcional del éxito. Qué asume específicamente NordFlux en esto se encuentra en nuestra página sobre consultoría de UiPath y automatización de procesos en general.

¿Qué pertenece al entorno de prueba y reversión?

Un entorno de prueba para RPA solo es útil si tiene el mismo nivel de parches y el mismo escalado de pantalla que la producción. De lo contrario, está probando un sistema diferente y pasará por alto exactamente la desviación que rompe el selector.

La ruta de reversión debe estar planeada antes del primer día de parches. Tres puntos son suficientes como equipo mínimo:

• Instantánea antes de la actualización: para máquinas robot virtuales, un punto de control inmediatamente antes de la ventana de mantenimiento. Esta es la forma más rápida de volver a un estado funcional.
• Mantener la versión de automatización: la última versión del proceso que se ejecutó con éxito permanece disponible en el Orchestrator para que un retroceso no falle por un paquete faltante.
• Ruta de reemplazo manual: para cada proceso crítico para el negocio debe documentarse cómo funciona un día sin robot. Sin este plan, un problema de parches se convierte en un problema de entrega.

Preguntas frecuentes

¿Cuándo es exactamente Patch Tuesday?

Microsoft publica las actualizaciones de seguridad mensuales para Windows el segundo martes de cada mes, generalmente a las 10:00 a.m. Hora del Pacífico, lo que corresponde a última hora de la noche en Alemania. Además, hay una actualización de vista previa opcional el cuarto martes sin contenido de seguridad y lanzamientos fuera de banda según sea necesario sin una fecha fija.

¿Puedo simplemente desactivar las actualizaciones de Windows en máquinas robot?

No, eso solo traslada el problema y crea un riesgo de seguridad. Las actualizaciones de seguridad mensuales son acumulativas, un seguimiento posterior trae todos los cambios omitidos a la vez y, por lo tanto, un mayor riesgo de ruptura que un pequeño paso regular. Lo sensato es un plan escalonado con una ventana de mantenimiento fija, no la suspensión.

¿Cómo sé que un selector se ha roto por una actualización?

Lo típico es un error al encontrar el elemento que aparece por primera vez exactamente después de una ventana de mantenimiento y siempre en el mismo lugar en el proceso. UiPath cita como causas, entre otros, actualizaciones del navegador, interfaces cambiadas de la aplicación objetivo y escalado diferente entre prueba y producción. Primero verifique si el error ocurre en todas las máquinas o solo en las ya parcheadas.

¿Es suficiente la notificación por correo electrónico del Orchestrator como monitoreo?

Para el nivel técnico sí, para el nivel funcional no. El resumen de diez minutos reporta alarmas de los niveles Fatal y Error oportunamente, pero no reporta cuando un trabajo se ejecuta técnicamente sin problemas y procesa cero registros. Por lo tanto, complemente con una verificación de cantidad que compare el número de registros procesados realmente con un valor esperado.

¿Cuál es el primer paso si los robots se desactivan regularmente después de las actualizaciones?

Coloque por escrito la ventana de mantenimiento y el cronograma del robot uno al lado del otro y verifique si la actualización se completó antes de la primera ejecución. Generalmente es el orden el problema, no la automatización. Solo después vale la pena trabajar en selectores más robustos.