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:
- En la base de datos de Connection Broker (tabla
rds.Server
). - En el registro de Windows bajo distintas claves de RDGateway, RDWebAccess y Terminal Services.
- En IIS, dentro de bindings HTTPS,
web.config
del portal RDWeb y definiciones de aplicaciones. - En Active Directory Sites and Services como objeto de equipo con vínculos de sitio.
- En DNS, normalmente como registros A/AAAA y (a veces) CNAME.
- En las RemoteApps publicadas y en los certificados con SAN que apuntan al FQDN.
- 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:
- Activa el trazado DCOM:
• Ejecutadcomcnfg
→ Component Services.
• En My Computer, abre Properties → Default Properties y habilita “Enable Distributed COM”.
• Pestaña Tracing → Log to file. - Reproduce el error y observa el archivo
%windir%\Tracing\DCOM*.log
. Anota CLSID y APPID. - 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.