Configurar WSUS básico en red local paso a paso

Montar un servidor WSUS en una red local es una de esas tareas que parecen sencillas sobre el papel, pero que puede volverse un pequeño infierno si no se planifica bien la topología, la seguridad y la configuración de los clientes. Si además el entorno no tiene salida directa a Internet o hay que trabajar con servidores de importación y exportación, los matices se multiplican.

En esta guía vas a ver cómo instalar y configurar un WSUS básico en red local, qué puertos y dominios necesita, cómo protegerlo con TLS, cómo organizar grupos de equipos y, sobre todo, cómo preparar las GPO para que los clientes usen tu WSUS en lugar de irse a Windows Update. También verás los puntos clave cuando trabajas con entornos desconectados (offline) y cómo evitar muchos de los problemas típicos de rendimiento y sincronización.

Qué es WSUS y por qué montarlo en una red local

Windows Server Update Services, o WSUS, es el servicio de Microsoft para centralizar las actualizaciones de Windows y otros productos (Office, SQL Server, etc.) dentro de una organización. En lugar de que cada equipo se conecte por su cuenta a Internet, todos consultan a tu servidor WSUS interno.

Esto reduce de forma muy notable el consumo de ancho de banda, permite tener un control fino sobre qué parches se instalan y cuándo, y facilita cumplir políticas de seguridad y auditoría ya que puedes aprobar, rechazar o retrasar actualizaciones según tus necesidades.

En redes corporativas medianas o grandes, además, WSUS suele ser la base para un plan de actualización por fases: se filtran primero los parches problemáticos, se prueban en un grupo piloto y, si todo va bien, se van liberando para el resto de usuarios y servidores.

Requisitos previos y consideraciones de diseño

Antes de entrar a clicar en asistentes, hay que tener claros algunos puntos básicos. Si los resuelves al principio, te ahorrarás horas de troubleshooting después con errores como el famoso 80244019 o problemas de sincronización.

Para un WSUS básico en red local, lo mínimo recomendable es contar con Windows Server 2016, 2019 o 2022 (aunque en muchos entornos aún hay 2012 R2 funcionando perfectamente), con permisos de administrador local en el servidor donde se va a instalar el rol.

A nivel de hardware, WSUS tira bastante de disco y memoria. Para un entorno medio, es razonable empezar con al menos 8 GB de RAM y un disco dedicado para el contenido de actualizaciones con 50-100 GB como punto de partida, mejor si se trata de un volumen separado del sistema para no llenarte la unidad C: con parches.

Otro punto clave es decidir si usarás la base de datos interna WID o una instancia de SQL Server remota. La base de datos interna simplifica mucho la instalación y es suficiente para la mayoría de despliegues. Si optas por SQL remoto, ten en cuenta luego las implicaciones de seguridad y el tráfico entre WSUS y SQL, sobre todo si quieres cifrar esa comunicación.

Puertos, firewall y conectividad a Microsoft Update

Uno de los errores de diseño más habituales es olvidarse del firewall perimetral o del propio firewall del servidor. WSUS necesita poder hablar con Microsoft Update usando HTTP y HTTPS para descargar metadatos y contenido.

Si tu servidor WSUS es el primero de la jerarquía (el servidor ascendente) y tiene salida a Internet, debe poder conectarse de salida a los puertos 80 y 443 hacia una serie de dominios de Microsoft. Aunque muchas empresas ya permiten HTTPS saliente sin restricciones, otras bloquean por defecto los servidores que no son de usuario.

Para que WSUS sincronice sin problemas, el firewall debe permitir las conexiones salientes a, entre otros, estos dominios:

• windowsupdate.microsoft.com y subdominios *.windowsupdate.microsoft.com
• *.update.microsoft.com y *.windowsupdate.com
• download.windowsupdate.com y *.download.windowsupdate.com
• download.microsoft.com, wustat.windows.com y go.microsoft.com
• dl.delivery.mp.microsoft.com y *.delivery.mp.microsoft.com

No hace falta que te los aprendas de memoria, pero sí que el equipo de seguridad entienda que bloquear estos destinos rompe WSUS. Si se van a gestionar actualizaciones de Microsoft 365 a través de Configuration Manager, la lista de dominios permitidos puede ampliarse aún más.

En entornos desconectados, donde el servidor de importación sí tiene salida a Internet pero el de exportación está en una red aislada, esta regla aplica únicamente al servidor que sincroniza con Microsoft Update. El WSUS de la red aislada solo necesitará hablar con el servidor de importación mediante los puertos internos configurados.

Puertos internos entre servidores WSUS y hacia los clientes

A nivel interno, todos los servidores WSUS y equipos cliente deben poder llegar al servidor WSUS correspondiente usando los puertos configurados. De fábrica, WSUS utiliza 8530 para HTTP y 8531 para HTTPS en IIS.

Si montas una jerarquía con varios WSUS, los servidores descendentes tienen que poder abrir conexiones salientes hacia el WSUS de nivel superior en esos dos puertos (o en los que tú definas, siempre que mantengas la regla de que el puerto de HTTPS sea el de HTTP +1).

En cuanto a los clientes, cada equipo que vaya a recibir actualizaciones deberá disponer de acceso de salida a esos mismos puertos 8530/8531 en el servidor WSUS. Si tienes firewalls internos o segmentación de red muy rígida, revisa bien las ACL para que no se quede ningún segmento aislado.

No es obligatorio usar 8530/8531; puedes cambiar a 80/443 si lo deseas, pero eso implica ajustar tanto la configuración de IIS como la URL que se configura en las GPO. Lo más habitual en entornos bien organizados es dejar los puertos por defecto de WSUS y abrirlos en los firewalls internos.

Uso de servidores proxy con WSUS

En muchas empresas, el acceso a Internet de los servidores pasa por uno o varios proxy corporativos. En ese escenario, WSUS también debe configurarse para usar ese servidor proxy para HTTP y HTTPS, respetando el tipo de autenticación requerido.

El proxy debe admitir tráfico HTTP y HTTPS con autenticación básica o de Windows. Esto se puede cubrir de dos maneras: usando un único proxy que maneje ambos protocolos (ideal) o separando en dos proxies, uno para HTTP y otro para HTTPS.

Si necesitas configurar dos proxies diferentes, puedes dejar el asistente de WSUS sin proxy y posteriormente usar la herramienta de línea de comandos wsusutil para declarar específicamente el proxy SSL, con algo equivalente a:

wsusutil ConfigureSSLproxy [servidor-proxy puerto-proxy] -enable

Para configurar, cambiar o eliminar un proxy desde la consola, basta con ir a Opciones → Origen de actualización y servidor proxy y, en la pestaña de servidor proxy, marcar o desmarcar el uso de proxy y, si es necesario, indicar credenciales y habilitar autenticación básica. Desde ahí puedes también borrar completamente la configuración de proxy cuando deje de ser necesaria.

Instalación del rol de WSUS en Windows Server

La instalación del rol se hace normalmente desde el Administrador del servidor usando el asistente de roles y características, aunque también es posible hacerlo por PowerShell. Los pasos, eso sí, son muy parecidos en todas las versiones modernas de Windows Server.

Primero inicias sesión en el servidor donde irá WSUS con una cuenta miembro del grupo de Administradores locales. Desde el Administrador del servidor eliges Agregar roles y características, seleccionas instalación basada en características o en roles, escoges el servidor destino y, en la lista de roles, activas Windows Server Update Services.

El asistente añadirá automáticamente las características requeridas, como las herramientas de administración de WSUS y los componentes básicos de IIS. Es importante no desmarcar estos elementos salvo que tengas muy claro lo que haces.

Más adelante, el asistente te pedirá la ruta donde se almacenarán las actualizaciones. Lo ideal es definir una carpeta en un segundo disco (por ejemplo, D:\WSUS o similar). Si no se especifica ruta, WSUS puede tirar de una ubicación por defecto que no siempre es lo más adecuado a nivel de capacidad y rendimiento.

En versiones como Windows Server 2019 o 2022, también se elige si se usará la base de datos WID (Windows Internal Database) o un SQL Server ya existente. Para un WSUS básico, la WID suele ser suficiente y te evita tener que gestionar instancias adicionales de SQL.

Configuración inicial con el asistente de WSUS

Una vez completada la instalación del rol y las tareas de post-instalación, abres la consola de administración de WSUS desde Herramientas en el Administrador del servidor. La primera vez aparecerá el Asistente de configuración.

Tras una pantalla inicial de bienvenida y la decisión de participar o no en el Programa de mejora de Microsoft Update, llega la parte importante: elegir si este WSUS se va a sincronizar directamente desde Microsoft Update o desde otro servidor WSUS ascendente. En entornos con varias sedes suele haber un WSUS central en la sede principal y WSUS secundarios que se sincronizan desde él.

Si optas por sincronizar desde otro WSUS, debes especificar el nombre del servidor y el puerto que se utilizará para la comunicación, y marcar si la sincronización se hará usando SSL (TLS) o no. En caso de usar TLS, el puerto por defecto es el 443, siempre que se haya configurado correctamente en IIS.

En esa misma fase del asistente puedes señalar si el servidor va a ser una réplica del servidor ascendente. Un WSUS en modo réplica hereda productos, clasificaciones, grupos y reglas del servidor padre, y limita ciertas acciones de administración local, lo que es útil cuando quieres estandarizar la configuración.

Luego se configura, en caso de ser necesario, el servidor proxy que usará WSUS para conectarse a Internet, incluyendo el nombre DNS, el puerto y las credenciales de usuario, así como la opción de habilitar autenticación básica si así lo requiere la infraestructura.

Selección de idiomas, productos y clasificaciones

En la parte de selección de idiomas, puedes optar por descargar actualizaciones en todos los idiomas o solo en un subconjunto. Cuantos menos idiomas selecciones, menos espacio en disco consumirá WSUS, pero asegúrate de incluir todos los idiomas que realmente se utilicen en los equipos de tu red.

Después, el asistente te pide elegir los productos de Microsoft para los que quieres obtener actualizaciones. Puedes marcar categorías completas como Windows o seleccionar productos concretos como Windows Server 2019, Windows 10, SQL Server, Microsoft 365 Apps, etc. Conviene ser conservador aquí: activar todo en un entorno grande es receta segura para un WSUS con miles y miles de parches innecesarios.

A continuación se eligen las clasificaciones de actualización: actualizaciones críticas, actualizaciones de seguridad, service packs, actualizaciones de definiciones (antimalware), service packs, actualizaciones acumulativas y así sucesivamente. De nuevo, puedes decidir si necesitas absolutamente todo o centrarte en lo crítico y de seguridad para empezar.

Por último, se define la programación de sincronización. Puedes optar por sincronizar de forma manual, iniciando el proceso tú desde la consola, o por una sincronización automática varias veces al día. Lo habitual es programar entre una y cuatro sincronizaciones al día, por ejemplo cada 6 horas, en ventanas horarias donde no penalice demasiado la salida a Internet.

En el último paso, el asistente ofrece iniciar la sincronización inicial de inmediato. Esa primera sincronización tarda bastante más que las siguientes, porque es cuando se descargan por primera vez todos los metadatos de los productos y clasificaciones seleccionados.

Protección de WSUS con TLS/HTTPS

Aunque WSUS puede funcionar enteramente sobre HTTP, lo recomendable, especialmente en redes donde circula información sensible, es activar TLS/HTTPS para proteger las conexiones entre clientes, servidores WSUS y eventuales servidores de base de datos.

El primer paso es habilitar TLS en Internet Information Services (IIS) del servidor WSUS. Esto implica disponer de un certificado TLS/SSL válido, emitido por una CA interna o externa, cuyo nombre coincida con el FQDN del servidor WSUS.

Una vez instalado el certificado en el servidor y configurado IIS para aceptar HTTPS, se acostumbra a usar el puerto 8531 para conexiones HTTPS y el 8530 para HTTP. Es importante respetar la regla de que el puerto de HTTPS sea el de HTTP más uno, ya que WSUS asume esa relación.

En cuanto a las aplicaciones de IIS, solo es necesario requerir TLS en determinadas raíces virtuales, como SimpleAuthWebService, DSSAuthWebService, ServerSyncWebService, APIremoting30 y ClientWebService. Otras carpetas como Contenido, Inventory, ReportingWebService o AutoUpdate no deben estar obligadas a usar TLS para evitar problemas de funcionamiento.

El certificado de la CA que firma el certificado del servidor WSUS debe importarse en el almacén de entidades de certificación raíz de confianza de cada servidor WSUS y de los equipos cliente, o en el almacén raíz de confianza específico del servicio de actualización automática si existe. Si no confían en esa CA, los clientes rechazarán la conexión TLS.

Para que WSUS use el certificado TLS/SSL en sus conexiones de cliente, se puede ejecutar en el servidor el comando de wsusutil usando como parámetro el nombre DNS del servidor WSUS, lo que termina de vincular la parte lógica del servicio con el certificado instalado en IIS.

Seguridad adicional: SQL remoto e IPsec

Si tu infraestructura utiliza un SQL Server remoto para la base de datos de WSUS, debes tener en cuenta que, por defecto, la comunicación entre el servidor WSUS y la base de datos no se cifra con TLS. Eso abre una posible vía de ataque en redes donde se pueda monitorizar tráfico interno.

Existen tres estrategias para endurecer este punto: mover la base de datos SUSDB al propio servidor WSUS para que la comunicación quede en local, colocar el servidor de base de datos y el WSUS en una red privada aislada del resto de segmentos, o implementar IPsec entre ambos para cifrar el tráfico SQL a nivel de red.

En muchas organizaciones se opta por una combinación de estos enfoques: base de datos en la misma VLAN que WSUS, sin ruteo directo desde otras redes de usuario y políticas de firewall muy restrictivas para limitar quién puede hablar con SQL y en qué puertos.

Publicación local y firma de código

Además de distribuir las actualizaciones de Microsoft, WSUS permite la llamada publicación local, es decir, crear tus propios paquetes de actualización con binarios personalizados o scripts que quieras desplegar con la misma lógica de aprobación que los parches oficiales.

Para usar correctamente la publicación local, es necesario contar con un certificado de firma de código específico, que se usará para firmar esos paquetes. Los equipos cliente, a su vez, deben estar configurados para confiar en ese certificado de firma para que acepten e instalen ese contenido.

La configuración detallada de la publicación local y la gestión de certificados de firma va más allá de un WSUS básico, pero debes tenerla en el radar si tu objetivo es aprovechar al máximo el entorno y automatizar despliegues internos más allá de lo que ofrece Windows Update.

Organización en grupos de equipos de WSUS

Un WSUS sin grupos de equipos bien pensados se convierte rápidamente en un caos. Los grupos de equipos permiten dirigir y escalonar las actualizaciones, probar primero en un subconjunto reducido y luego ampliar el despliegue de forma controlada.

De fábrica existen dos grupos especiales: Todos los equipos y Equipos sin asignar. Cada nuevo equipo que se comunica por primera vez con el servidor WSUS aparece automáticamente en ambos.

A partir de ahí, puedes crear tantos grupos personalizados como necesites: Piloto, Producción, Servidores, Puestos de oficina, Laboratorio, etc. Buenas prácticas habituales recomiendan tener, como mínimo, un grupo de pruebas donde validar las actualizaciones recién aprobadas antes de liberarlas a toda la organización.

Los grupos se crean desde la consola de WSUS, en el apartado Equipos, haciendo clic derecho sobre Todos los equipos y usando la opción para agregar nuevo grupo, donde das un nombre representativo y listo.

Destino del lado servidor vs destino del lado cliente

WSUS ofrece dos modelos para asignar equipos cliente a grupos: el destino del lado servidor (server-side targeting) y el destino del lado cliente (client-side targeting). La elección afecta directamente a cómo se gestiona la pertenencia a grupos.

En el modelo de lado servidor, que es el predeterminado, el administrador asigna los equipos a los grupos directamente desde la consola de WSUS. Eso te permite arrastrar, mover equipos entre grupos y ajustar rápido cuando haya cambios o incidencias.

El inconveniente es que cualquier equipo nuevo aparecerá en Equipos sin asignar y tendrás que acordarte de moverlo manualmente al grupo correcto. En redes dinámicas, con alta rotación de equipos, esto puede volverse pesado si no se automatiza de alguna forma.

En el enfoque de lado cliente, son los propios equipos los que, mediante directivas de grupo o configuraciones de Registro, se “autoasignan” a uno o varios grupos de WSUS. La ventaja es que los nuevos equipos llegan ya clasificados al servidor según la GPO que les apliques (por ejemplo, según su OU o tipo de equipo).

A cambio, ya no puedes cambiar la pertenencia a grupos desde la consola de WSUS: si quieres mover un equipo de Piloto a Producción, tendrás que modificar la GPO, el Registro o el grupo de AD al que pertenece. Es un modelo menos flexible en tiempo real, pero mucho más escalable en entornos grandes.

Configuración de clientes mediante directivas de grupo

Por defecto, cualquier Windows está configurado para consultar Windows Update en Internet. Para que empiece a usar tu servidor WSUS, debes modificar la configuración de Windows Update en los equipos.

Si tu organización usa Active Directory, lo normal es crear uno o varios GPO específicos para WSUS y vincularlos al dominio o a las unidades organizativas correspondientes. Es buena idea que estas GPO contengan solo configuración de WSUS para tenerlas bien localizadas.

Desde la Consola de administración de directivas de grupo, editas el GPO elegido y navegas a Configuración del equipo → Directivas → Plantillas administrativas → Componentes de Windows → Windows Update. En versiones modernas (Windows 10, Windows 11) suele haber un subapartado de Administrar experiencia del usuario final o similar.

La primera configuración a tocar es Configurar actualizaciones automáticas. Ahí marcas Habilitada y eliges el comportamiento, por ejemplo «Descargar automáticamente y programar la instalación», con la hora deseada para servidores o puestos de usuario. Así te aseguras de que las actualizaciones aprobadas se descargan y aplican sin intervención del usuario.

La siguiente directiva clave es Especificar la ubicación del servicio de actualización de Microsoft en la intranet (o «Especificar la ubicación del servicio Windows Update en la intranet»). Debes habilitarla e indicar la URL de tu WSUS en ambos cuadros: tanto el de detección como el de estadísticas, con la forma http://NOMBRE_SERVIDOR:8530 o https://NOMBRE_SERVIDOR:8531 según uses TLS o no.

Si has decidido trabajar con destino del lado cliente, también hay que habilitar la directiva llamada Habilitar destinatarios del lado cliente y, dentro de ella, rellenar el campo de nombre de grupo de destino con el grupo WSUS al que quieres que se asigne el equipo. Puedes incluso especificar varios grupos separados por punto y coma, por ejemplo Servidores;Piloto.

Aplicación de GPO y detección inicial de actualizaciones

Una vez configuradas las GPO, hay que dar tiempo a que los equipos cliente reciban y apliquen la nueva configuración. En dominios con Active Directory, la actualización de directivas es periódica, pero puedes forzarla usando el comando gpupdate /force en una ventana de símbolo del sistema con privilegios elevados.

Después se recomienda reiniciar el equipo cliente para garantizar que el servicio de Windows Update recoja completamente los cambios de política. A partir de ahí, el cliente debería conectarse a tu WSUS según la programación de búsqueda de actualizaciones definida.

Si quieres acelerar el proceso, especialmente durante las pruebas, puedes forzar una detección inmediata. En Windows 10 y 11, basta con ir a la aplicación de Configuración, entrar en Windows Update y pulsar Buscar actualizaciones. En versiones antiguas, se puede usar el icono de Windows Update del Panel de control.

En sistemas previos a Windows 10, además, se puede recurrir al comando wuauclt /detectnow desde una consola elevada para forzar la detección. Pasados unos minutos, el equipo debería aparecer en la consola de WSUS bajo el grupo Todos los equipos y, según el modelo de destino elegido, o bien en Equipos sin asignar o bien en el grupo asignado vía GPO.

A partir de ese momento, si hay actualizaciones aprobadas para ese equipo, verás que empieza a descargar e instalar parches, y WSUS reflejará en su consola el estado (Necesaria, Instalando, Instalado correctamente, etc.).

Gestión básica: aprobaciones y reglas automáticas

La funcionalidad real de WSUS llega cuando empiezas a aprobar o rechazar actualizaciones. Desde la consola, en la sección Actualizaciones, puedes ver todas las actualizaciones disponibles por categorías, productos y estados.

Seleccionando una o varias actualizaciones, puedes dar clic derecho y escoger Aprobar, eligiendo después para qué grupo o grupos de equipos se aprobará: Piloto, Servidores, Puestos, etc. Es posible aprobar para instalación, para desinstalación o incluso dejar la actualización explícitamente rechazada.

Para evitar tener que hacerlo todo a mano, WSUS admite la creación de reglas de aprobación automática. Por ejemplo, podrías establecer que toda actualización de seguridad para Windows Server se apruebe automáticamente para el grupo Piloto, o que las definiciones de antivirus se apliquen a todos los equipos sin intervención.

En entornos donde un servidor está configurado como réplica de otro WSUS, muchos de estos ajustes llegan heredados del servidor ascendente y el servidor réplica limita bastante lo que puedes modificar: no podrás cambiar grupos ni reglas de aprobación desde él, precisamente porque su función es reflejar la configuración del WSUS padre en otra ubicación o red.

Si estás montando un WSUS de exportación en una red aislada, conviene pensar bien si debe seguir en modo réplica o si te interesa desactivar ese modo para poder gestionar grupos y aprobaciones localmente, asumiendo que ya no va a hablar directamente con el WSUS de importación más que para importar metadatos y contenido.

Consideraciones para entornos desconectados y errores típicos

Cuando trabajas con un escenario de exportación/importación WSUS, en el que un servidor con Internet sincroniza con Microsoft Update y luego exporta las actualizaciones a un servidor sin salida a Internet, hay varios matices que suelen dar guerra.

El servidor configurado estrictamente como réplica del WSUS de importación no te permitirá crear grupos adicionales, cambiar reglas de aprobación ni gestionar muchas opciones locales. Si necesitas esa flexibilidad, tendrás que replantearte el rol del servidor de exportación y tratarlo como un WSUS «normal» que recibe el contenido y los metadatos pero se administra de forma independiente.

Errores como el código 80244019 en los clientes al buscar actualizaciones suelen apuntar a problemas de conectividad con el WSUS, fallos de autenticación, configuración errónea en las GPO (URL de WSUS incorrecta, por ejemplo) o incluso a que el propio servidor WSUS esté sobrecargado, mal dimensionado o con un IIS inestable.

Otro escenario frecuente son servidores WSUS antiguos saturados, donde el asistente de limpieza se cuelga, la base de datos SUSDB está inflada y el proceso sqlservr consume casi toda la RAM. En estos casos, suele ser más inteligente preparar un servidor WSUS nuevo desde cero, con mejor tamaño de disco, reglas de sincronización más ajustadas y una estrategia de mantenimiento regular, que seguir parcheando una instalación rota.

Si usas máquinas virtuales en plataformas como VMware, da buen resultado asignar una cantidad razonable de recursos desde el inicio (varios vCPU, RAM suficiente, disco rápido para la base de datos y otro disco grande para el contenido) y planificar tareas de limpieza periódica de actualizaciones obsoletas, equipos inactivos y versiones antiguas de productos descontinuados.

Con todo lo anterior bien atado —requisitos, puertos, firewall, TLS, grupos, GPO y, si aplica, la particularidad de redes aisladas— un WSUS básico en red local se convierte en una pieza muy fiable para controlar las actualizaciones de toda la organización, reduciendo consumo de ancho de banda, mejorando la seguridad y permitiéndote decidir, con bastante margen, cuándo y cómo se instalan los parches en servidores y estaciones de trabajo.