Los errores DCOM (ID 10028) y las advertencias RDWebAccess (ID 5) pueden convertirse en una auténtica pesadilla cuando una puerta de enlace RDS insiste en contactar a un servidor que ya no existe. Este artículo explica por qué ocurre, dónde se almacenan las “huellas” que provocan los eventos y cómo eliminarlas de forma segura y definitiva.

Entendiendo el problema

Un servidor de Remote Desktop Gateway encapsula sesiones RDP dentro de HTTPS. Cuando ese GW aplica reglas de autorización o publica RemoteApps, se apoya en varios roles y componentes: RD Web Access, Connection Broker, IIS, SQL o Windows Internal Database, objetos de Active Directory y registros DNS. Si cualquiera de esas piezas contiene el FQDN de un host retirado, el GW volverá a solicitarlo cíclicamente, generando:

• Eventos DCOM 10028: “Ping para CLSID {GUID} en SERVIDOR_ELIMINADO.FAKEORG.com ha superado el tiempo de espera …”.
• Eventos RDWebAccess 5: “No se pudo iniciar la consulta sobre el host SERVIDOR_ELIMINADO …”.

El origen real casi nunca es DCOM; DCOM sólo refleja la llamada fallida. La clave está en limpiar todas las referencias internas restantes.

Por qué aparecen “fantasmas” tras eliminar un host

Cuando se añade un servidor a un deployment RDS, su nombre se copia en múltiples lugares:

1. En la base de datos de Connection Broker (tabla rds.Server).
2. En el registro de Windows bajo distintas claves de RDGateway, RDWebAccess y Terminal Services.
3. En IIS, dentro de bindings HTTPS, web.config del portal RDWeb y definiciones de aplicaciones.
4. En Active Directory Sites and Services como objeto de equipo con vínculos de sitio.
5. En DNS, normalmente como registros A/AAAA y (a veces) CNAME.
6. En las RemoteApps publicadas y en los certificados con SAN que apuntan al FQDN.
7. En GPO, scripts de inicio y tareas programadas que automatizan copias o auditorías.

Al formatear el servidor o simplemente apagarlo, lo eliminamos de la capa física, pero sus metadatos persisten e intentan resolverse cada pocos minutos. La puerta de enlace los busca “por si vuelven” para mantener la topología consistente. De ahí los errores.

Diagnóstico estructurado

A continuación se detalla un recorrido completo, empezando por lo evidente y terminando en zonas menos conocidas. Sigue cada bloque hasta que los eventos cesen.

Área que revisar	Acción recomendada	Objetivo
Despliegue RDS	En Server Manager → Remote Desktop Services inspecciona los roles. Si el host antiguo aparece, usa Remove‑RDServer o el asistente para borrarlo.	Eliminarlo del inventario oficial.
DNS	Suprime registros A/AAAA/CNAME del servidor retirado.	Evitar resolución de nombre.
Active Directory Sites and Services	Comprueba que no quede el objeto de servidor ni vínculos.	Limpieza de metadatos AD.
IIS (GW/RDWeb)	Revise bindings, web.config y application pools; elimine rutas al host.	Detener llamadas RDWeb fantasma.
Registro	Busque el FQDN en: HKLM\SOFTWARE\Microsoft\RDGateway HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Services HKLM\SOFTWARE\Microsoft\RDWebAccess	Quitar claves residuales.
Base de datos Broker	Con SQL Server Management Studio o PowerShell: SELECT * FROM rds.Server WHERE Name LIKE '%ELIMINADO%'; — y luego DELETE.	Purgar asignaciones internas.
Certificados y RemoteApps	Renueva certificados sin el SAN obsoleto y reemite archivos RDP.	Prevenir advertencias.
GPO y tareas	Filtra GPO con Get-GPO -All | ?{$_.DisplayName -match 'ELIMINADO'}. Revise acciones.	Eliminar conexiones automáticas.

1. Auditoría del deployment RDS

La consola gráfica muestra de un vistazo los servidores asignados. Sin embargo, PowerShell revela metadatos que a veces no aparecen en la UI:

Import-Module RemoteDesktop
Get-RDServer
Remove-RDServer -Server "DELETED_SERVER.FAKEORG.com" -Role RDSH,RDWA,RDGateway -Force

Si da error “No se pudo actualizar la base de datos RDMS”, pasa al paso 6 y elimina manualmente las filas que hacen referencia al host.

2. Limpieza DNS

En entornos mixtos IPv4/IPv6 basta un registro olvidado para prolongar las búsquedas. Ejecuta:

dnscmd /enumrecords fakeorg.com DELETED_SERVER /type A
dnscmd /recorddelete fakeorg.com DELETED_SERVER A /f

Luego limpia caché del GW:

ipconfig /flushdns

3. Depuración en Active Directory

Abre Active Directory Sites and Services, habilita “Show Services Node” y explora CN=Windows NT. Si quedase un serverReference, bórralo. Alternativamente:

dsquery * "CN=Configuration,DC=fakeorg,DC=com" -filter "(dnsHostName=DELETED_SERVER.FAKEORG.com)" | dsrm -noprompt

4. Inspección detallada de IIS

Las llamadas RDWeb se orquestan mediante Pages\rdp.js y web.config. Busca el FQDN con:

cd "C:\Windows\Web\RDWeb\Pages"
Select-String -Path .js,.config -Pattern "DELETED_SERVER"

Modifica los archivos o usa el editor avanzado de bindings para eliminar puertos asociados (típicamente 443 y 3391).

5. Registro de Windows

Una búsqueda global es lenta; delimita las ramas afectadas:

reg query HKLM\SOFTWARE /f "DELETEDSERVER" /t REGSZ /s

Borra exclusivamente valores ServerName o HostToPing dentro de claves RDS; no toques GUIDs de CLSID porque pertenecen a otras aplicaciones.

6. Depuración de la base de datos RDMS

Si tu Broker usa Windows Internal Database, conéctate así:

sqlcmd -E -S np:\\.\pipe\MSSQL$MICROSOFT##WID\tsql
1> USE RDCms;
2> SELECT Id,Name FROM rds.Server WHERE Name LIKE '%DELETED_SERVER%';
3> DELETE FROM rds.Server WHERE Id = 7;

Para SQL Server, basta con SSMS. Recuerda hacer backup antes.

7. Certificados y RemoteApps

Ejecuta certlm.msc y abre el certificado de la puerta de enlace. En Subject Alternative Name nunca debe aparecer el host retirado. Renueva si es necesario y publica de nuevo las RemoteApps:

Get-RDRemoteApp | Set-RDRemoteApp -GatewayExternalFqdn "rdgw.fakeorg.com"

8. GPO, scripts y tareas programadas

Las directivas que asignan impresoras o mapean unidades pueden seguir apuntando al servidor desaparecido. Encontrarlas manualmente es inviable; usa filtros:

Get-ScheduledTask | ?{$.Actions -match "DELETEDSERVER"} | Disable-ScheduledTask
Get-ChildItem "\\fakeorg.com\SYSVOL\fakeorg.com\Policies\" -Recurse -Include .bat,.ps1 | Select-String "DELETED_SERVER"

Comprobaciones avanzadas

Si tras la limpieza aún ves eventos 10028 y 5:

1. Activa el trazado DCOM:
     • Ejecuta dcomcnfg → Component Services.
     • En My Computer, abre Properties → Default Properties y habilita “Enable Distributed COM”.
     • Pestaña Tracing → Log to file.
2. Reproduce el error y observa el archivo %windir%\Tracing\DCOM*.log. Anota CLSID y APPID.
3. Consulta el registro para ese GUID:
   reg query HKCR\CLSID\{GUID}
   …busca la ruta (LaunchPermission, AppID) e investiga los binarios que cargan la llamada.

El propio binario suele revelar la referencia persistente. Ejemplos comunes: tsgateway.dll, tswebaccess.dll o complementos de terceros (antivirus, impresión universal).

Reinicio de servicios y verificación

Después de cada bloque de limpieza reinicia los servicios para descartar memoria caché:

Restart-Service W3SVC
Restart-Service TSGateway
Restart-Service RDWebAccess

O si prefieres reiniciar por completo fuera de horario laboral:

Shutdown /r /t 0 /d P:2:17 /c "Reinicio tras limpieza RDS"

Vigila el Visor de eventos durante al menos 30 minutos (dos ciclos de registro predeterminados). La ausencia de nuevos 10028 y 5 confirma la desaparición del fantasma.

Prevención futura

• Plantillas de provisioning: crea scripts para añadir y retirar roles, evitando manipulación manual.
• Documenta dependencias: antes de desmantelar un host, ejecuta un inventario (PowerShell + export a CSV).
• Replication lag: espera siempre a que AD replique antes de desconectar físicamente el servidor.
• Auditoría programada: un trabajo mensual que ejecute Get-RDServer y envíe correo si detecta hosts apagados más de 48 h.
• Control de cambios: integra la salida de dnscmd /enumrecords en tu CMDB para visibilidad instantánea.

Conclusión

Los errores DCOM 10028 y RDWebAccess 5 tras eliminar un servidor no son fallos del Gateway sino síntomas de referencias huérfanas repartidas por el entorno. Siguiendo el recorrido — despliegue RDS, DNS, AD, IIS, registro, base de datos, certificados y GPO— eliminarás cada huella. Dedica tiempo a la fase de diagnóstico y conservarás un sistema limpio, fiable y sin entradas fantasmales.