Powershell

Error: no se puede encontrar un servidor predeterminado con ADWS

Portada del artículo «Error: no se puede encontrar un servidor predeterminado con ADWS» de Trucos Informáticos

Ejecutas un comando del módulo de Active Directory (Get-ADUser, Get-ADComputer, New-ADUser…) y PowerShell responde con este error: «Unable to find a default server with Active Directory Web Services running», en español, «No se puede encontrar un servidor predeterminado con los servicios web de Active Directory ejecutándose». También puede aparecer con otras formas parecidas: «Los servicios de dominio de Active Directory no están disponibles» o «El dominio especificado no existe o no se pudo contactar con él». Todos describen lo mismo: tu equipo no ha encontrado, o no ha podido hablar con, un controlador de dominio capaz de responder a las consultas del módulo. En esta guía verás qué son los Servicios web de Active Directory (ADWS), cómo localizar la causa en pocos minutos y cómo resolverla.

Qué son los Servicios web de Active Directory (ADWS)

El módulo de PowerShell de Active Directory no habla directamente con la base de datos del directorio: lo hace a través del servicio Servicios web de Active Directory (Active Directory Web Services, ADWS, nombre de servicio ADWS), que escucha en el puerto TCP 9389 de los controladores de dominio. Lo mismo ocurre con el Centro de administración de Active Directory. Si el servicio no está en ejecución en el controlador de dominio, si el puerto está bloqueado o si tu equipo no consigue encontrar ningún controlador de dominio, el módulo muestra este error.

Diagnóstico rápido: sigue este orden

  1. ¿Con qué usuario y desde qué equipo ejecutas el comando? (paso 1)
  2. ¿El equipo encuentra un controlador de dominio? DNS y localización (paso 2).
  3. ¿Responde el puerto 9389? Red y cortafuegos (paso 3).
  4. ¿Está el servicio ADWS iniciado en el controlador de dominio? (paso 4).
  5. ¿Está sano el controlador de dominio? Hora, replicación y registros (paso 5).

Paso 1: comprueba desde dónde y con quién ejecutas el comando

Este es el origen de la mitad de los casos y se pasa por alto con facilidad. Los cmdlets de Active Directory eligen automáticamente un controlador de dominio basándose en el dominio del usuario con el que has iniciado sesión. Si has iniciado sesión con una cuenta local o desde un equipo que no pertenece al dominio, no hay un dominio «predeterminado» y el módulo no sabe a quién preguntar. La solución es indicar el servidor explícitamente:

Get-ADUser -Identity l.gomez -Server dc01.empresa.local -Credential (Get-Credential)

# Para trabajar varios comandos seguidos con ese servidor, crea una unidad de Active Directory
New-PSDrive -Name ADEMP -PSProvider ActiveDirectory -Server 'dc01.empresa.local' -Credential (Get-Credential) -Root '//RootDSE/' -Scope Global
Set-Location ADEMP:
Get-ADUser -Filter * -ResultSetSize 5

Si estás en un equipo del dominio con una cuenta de dominio, comprueba que el equipo mantiene correctamente su relación con el dominio: Test-ComputerSecureChannel debe devolver True.

Paso 2: comprueba que el equipo localiza un controlador de dominio

La localización depende de DNS: el equipo busca registros especiales (registros SRV) para encontrar los controladores. Por eso el servidor DNS configurado en la tarjeta de red debe ser un controlador de dominio o un DNS que pueda resolver el dominio, no el de un proveedor de Internet ni un servidor público. Verifica:

# ¿Qué DNS usa este equipo?
Get-DnsClientServerAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, ServerAddresses

# ¿Resuelve los registros de los controladores de dominio?
nslookup -type=SRV _ldap._tcp.dc._msdcs.empresa.local

# ¿Qué controlador de dominio encuentra Windows?
nltest /dsgetdc:empresa.local

# ¿Encuentra uno con ADWS en marcha?
Get-ADDomainController -Discover -Service ADWS

Si nslookup no devuelve registros o el comando de descubrimiento falla, el problema está en DNS: corrige el servidor DNS del equipo (en una VPN o una red de invitados es lo más habitual) o revisa que el servicio DNS de los controladores tiene los registros SRV. Si el nombre del dominio no se resuelve ni siquiera con nslookup, el error «el dominio especificado no existe» casi siempre es esto.

Paso 3: comprueba el puerto 9389 y el cortafuegos

Test-NetConnection dc01.empresa.local -Port 9389

El resultado TcpTestSucceeded: True indica que el puerto es accesible. Si es False, algo lo bloquea: el cortafuegos de Windows del controlador, un cortafuegos de red entre subredes o la configuración de una VPN. En el controlador de dominio, la regla de entrada se llama Active Directory Web Services (TCP-In) y debe estar habilitada:

Get-NetFirewallRule -DisplayName '*Active Directory Web Services*' | Select-Object DisplayName, Enabled, Direction, Profile

Recuerda también que los cmdlets necesitan alcanzar otros puertos del directorio (como el 389 de LDAP y los de Kerberos). Si el cortafuegos de red está muy restringido, consulta con el responsable de la red qué flujos están permitidos entre tu equipo y los controladores.

Paso 4: comprueba el servicio ADWS en el controlador de dominio

Si el puerto no responde y no hay un cortafuegos de por medio, probablemente el servicio no se está ejecutando en el controlador. Desde cualquier equipo con permisos, o desde el propio controlador:

# Estado de los servicios clave del controlador de dominio
Get-Service -ComputerName dc01 -Name ADWS, NTDS, DNS, Netlogon, KDC | Select-Object Name, Status, StartType

# Iniciar ADWS si está detenido (en el propio controlador, como administrador)
Start-Service ADWS
Set-Service ADWS -StartupType Automatic

Algunos casos y su explicación:

  • ADWS tarda en arrancar tras un reinicio: si acabas de reiniciar el controlador, espera unos minutos antes de ejecutar comandos: ADWS arranca después de que lo haga el servicio de directorio.
  • ADWS no arranca: el servicio depende de que los Servicios de dominio de Active Directory (NTDS) estén funcionando. Si NTDS está detenido o en error, el problema es más profundo (base de datos, disco, replicación). Revisa los registros.
  • ADWS no existe: en dominios con controladores muy antiguos (anteriores a Windows Server 2008 R2) puede que ninguno tenga el servicio. Se instala el Active Directory Management Gateway Service en al menos uno, o se migra a controladores modernos.

El servicio escribe su propio registro de eventos, que suele dar la causa exacta del fallo. Consúltalo en el controlador:

Get-WinEvent -LogName 'Active Directory Web Services' -MaxEvents 20 | Format-Table TimeCreated, Id, LevelDisplayName, Message -Wrap

Si necesitas repasar el uso de Get-WinEvent y de otros comandos de diagnóstico, tienes ejemplos en nuestra guía de 10 comandos de PowerShell imprescindibles.

Paso 5: comprueba la salud del controlador de dominio

Si todo lo anterior está bien y el error persiste, revisa el estado general del controlador:

dcdiag /q                      # solo muestra los problemas
dcdiag /test:services /test:dns
repadmin /replsummary          # estado de la replicación entre controladores
w32tm /query /status           # hora y origen de la sincronización
  • Hora desincronizada: Kerberos tolera una diferencia máxima de cinco minutos entre equipos. Si el reloj de tu equipo o del controlador está desajustado, la autenticación falla. El origen de la hora en un dominio es el controlador con el rol de emulador de PDC.
  • Replicación rota: si el controlador que elige tu equipo tiene datos obsoletos o está aislado, puede responder mal. repadmin muestra los fallos.
  • Registros DNS ausentes o incorrectos: dcdiag /test:dns detecta registros SRV que faltan.

Casos típicos y su solución en una línea

  • Funciona en el controlador pero no en mi portátil: el portátil tiene un DNS distinto o una cuenta local (pasos 1 y 2).
  • Funciona por la mañana y falla desde casa: la VPN no entrega el DNS corporativo o no permite el puerto 9389.
  • Falla solo en un script programado: la tarea se ejecuta con otra cuenta o en un equipo sin dominio predeterminado; añade -Server a los comandos del script.
  • Falla justo después de reiniciar el controlador: espera a que arranque ADWS; añade reintentos al script.
  • Falla con un solo controlador de varios: el equipo está eligiendo uno con el servicio detenido; revisa ese controlador o fija tu consulta a uno sano con -Server.

Cómo evitar el problema en tus scripts

Si tus scripts dependen de Active Directory, hazlos resistentes a este tipo de fallos:

$dc = (Get-ADDomainController -Discover -Service ADWS -ErrorAction Stop).HostName[0]
Get-ADUser -Filter 'Enabled -eq $false' -Server $dc

Localizar primero un controlador con ADWS operativo y usarlo explícitamente hace tus consultas más predecibles. Para repetirlas ante fallos transitorios, envuelve la llamada en un bucle con un máximo de intentos, como los que explicamos en la guía de bucles en PowerShell. Y si quieres vigilar el estado del servicio ADWS en tus controladores, puedes programar una comprobación periódica con tareas programadas de PowerShell.

Cuando el módulo vuelva a responder, aprovecha para dejar ordenado el directorio con las buenas prácticas de la guía de usuarios y grupos de Active Directory.

Preguntas frecuentes

¿Hace falta instalar ADWS en mi equipo?

No. ADWS es un servicio del controlador de dominio al que se conecta el módulo. En tu equipo solo necesitas el módulo (RSAT).

¿Puedo cambiar el puerto 9389?

Es el puerto estándar de ADWS y no conviene modificarlo, porque las herramientas de administración esperan encontrarlo ahí. Lo normal es ajustar los cortafuegos para permitirlo.

El error aparece en el Centro de administración de Active Directory, ¿es lo mismo?

Sí: esa consola también usa ADWS. Si falla el puerto 9389 o el servicio, fallarán igual ella y PowerShell, pero la consola clásica Usuarios y equipos de Active Directory usa otros protocolos (LDAP) y puede seguir funcionando.

Conclusión

Este error significa que el módulo de Active Directory no ha podido hablar con el servicio ADWS de un controlador de dominio. Comprueba, por este orden, el equipo y la cuenta desde la que ejecutas (indica -Server si no estás en el dominio), el DNS que usa el equipo, el acceso al puerto 9389 y el servicio ADWS del controlador. Si todo eso está bien, revisa la hora y la replicación con dcdiag y repadmin. En tus scripts, localiza y fija el controlador de forma explícita para que sean más robustos.

Guías relacionadas

9 comentarios

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *