Una situación cada vez más habitual en los Software Updates Points con ConfigMgr, que no se presentaba con frecuencia en CM07, es la de encontrarnos con eventos 503 en los logs de sincronización del site server.
En el componente SMS_WSUS_SYNC_MANAGER del primario veremos eventos similares a este:
Message ID: 6703
WSUS Synchronization failed.
Message: The request failed with HTTP status 503: Service Unavailable.
Source: Microsoft.UpdateServices.Administration.AdminProxy.CreateUpdateServer.
La solución a esta situación está perfectamente documentada en este post:
Pero me gustaría explicar el origen de este evento y por qué cada vez es más habitual encontrarlo en los entornos con ConfigMgr.
Debido a los cambios en el servicing model en el sistema operativo y aplicaciones Microsoft en los últimos años, el volumen de versiones que se están generando se incrementa, el ciclo de creación y publicación de updates se está multiplicando, si a esto le sumamos que en las actuales versiones de ConfigMgr se nos permite seleccionar durante cuánto tiempo queremos mantener en el catalogo updates superseded, la consecuencia es que el catálogo de updates ha crecido prácticamente exponencialmente.
¿Qué consecuencias tiene este cambio para ConfigMgr?
La primera de ellas es la aparición de eventos 503 en los servidores con el role de SUP, ya que el Memory Application Pool que tiene IIS reservado para este servicio se ve agotado por las peticiones de descarga del catálogo de updates por los clientes, el servicio al ser sobrepasado en las peticiones es parado por el IIS para que no afecte al resto de servicios presentes.
¿Por qué esto es más difícil que ocurra con CM07?
En esta versión los updates superseded son eliminados por el site por diseño, lo que evita que el catalogo crezca en exceso, con lo que es menos probable, pero no imposible, que esto suceda.
¿Qué consecuencias tiene esto en mi entorno?
La más inmediata es que los clientes dejan de recibir actualizaciones, ya sean Updates o Definiciones de Edpoint Protection, por lo que en ciertos entornos esto se vuelve crítico.
¿Qué solución tenemos?
Aparte de la indicada en el post anterior es una práctica recomendada el llevar un mantenimiento regular de WSUS, su catálogo y sus bases de datos para evitar este crecimiento desmedido y sus consecuencias, además de ajustar el catálogo sincronizando únicamente a las aplicaciones presentes en mi entorno, no es recomendable sincronizarlo todo “por si acaso”.
Si el entorno es pequeño esto supone realizar WSUS Cleanups cada cierto tiempo (recomendado cada mes), indexar la base de datos de WSUS (que ya no es tan pequeña como solía) para mejorar su rendimiento y declinar los updates superseded más antiguos (Mediante un script de powershell podemos decidir de que antigüedad eliminamos).
En entornos grandes la recomendación es seguir este post de Microsoft donde se explica cómo automatizar todo el proceso:
Espero que haya resultado de utilidad para todos.
Esta información esta generada sin garantías de soporte, antes de implementar ningún cambio en producción o lanzar un script es recomendable testear con anterioridad en un laboratorio o entorno de test para ver posibles consecuencias según la particularidades de cada entorno.
Hasta el próximo post.
configmgryyo 