Sessões RDP que se fecham logo após o logon no Windows Server 2019 podem paralisar toda a operação. Veja como diagnosticar rapidamente e aplicar correções seguras em ambientes físicos ou VMware.
Visão geral do problema
Depois de anos de uso normal, você tenta se conectar via Remote Desktop e, poucos segundos após digitar as credenciais, a janela RDP some sem mensagens de erro visíveis. Esse comportamento costuma ser provocado por uma cadeia de fatores que vai de políticas de segurança recém‑aplicadas até falhas em drivers de rede virtual. Ignorar o alerta pode significar rodar scripts críticos diretamente no console do hypervisor ou atrasar manutenções, por isso vale a pena seguir um fluxo de análise estruturado.
Sintomas comuns observados
- Evento
Microsoft-Windows-RemoteDesktopServices-RdpCoreTS (Operational)com código de desconexão 0xC000006D ou 0xC000035B. - Logon é aceito (as credenciais não estão incorretas), mas o desktop nunca chega a ser exibido.
- Outras máquinas no mesmo host ESXi continuam aceitando RDP normalmente, indicando algo específico ao sistema convidado.
- Serviço TermService reinicia automaticamente no meio da negociação de sessão.
Matriz de diagnóstico rápido
| Área | Ação prática | O que procurar / corrigir |
|---|---|---|
| Logs de evento | Auditar em Event Viewer • Microsoft‑Windows‑RemoteDesktopServices‑RdpCoreTS ▶ Operational • TerminalServices‑RemoteConnectionManager ▶ Operational • TerminalServices‑LocalSessionManager ▶ Operational • Windows ▶ Security | Códigos de desconexão (ex.: 0xC000006D, 0xC000035B) que indicam falhas de autenticação, NLA ou certificados vencidos. |
| Rede | Executar ping, tracert ou Test‑NetConnection -ComputerName <servidor> -Port 3389Verificar MTU, jumbo frames e configurações de vSwitch ou port‑group no VMware. | Perda de pacotes, latência alta ou filtragem da porta 3389 por firewall/IPS. |
| Recursos do host | Abrir Task Manager ou Performance Monitor enquanto tenta conectar | Consumo de CPU ou RAM acima de 90 % pode matar o serviço TermService ou interromper a sessão na fase de logon. |
| Políticas de Grupo | Acessar gpedit.msc ▶ Computer Configuration ▸ Administrative Templates ▸ Windows Components ▸ Remote Desktop Services ▸ Remote Desktop Session Host ▸ Connections/Security | Limite de sessões, tempo ocioso ou exigência de criptografia incompatível. Configurações herdadas que forçam NLA ou TLS obsoleto. |
| NLA (Network Level Authentication) | Em System Properties ▶ Remote desmarcar “Allow connections only from computers running Remote Desktop with Network Level Authentication”. | Se a sessão abrir sem NLA, há problema de credenciais, certificado ou canal seguro (CredSSP). |
| Serviços RDP | Reiniciar Remote Desktop Services e Remote Desktop Services UserMode Port Redirector | Corrige estados travados sem reiniciar o servidor inteiro. |
| Licenciamento / certificados | Verificar servidor RDS Licensing e contador de CALs. Checar validade do certificado RDP (MMC ► Certificates ► Local Computer ► Remote Desktop). | Falta de CAL ou certificado expirado encerra a sessão após logon. |
| VMware Tools e drivers | Atualizar VMware Tools e drivers de placa de rede (VMXNET3, E1000) | Bugs conhecidos em versões antigas causam desconexão RDP. |
| Protocolo UDP | Alterar registro HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\fClientDisableUDP para 1 (DWORD) | Desativa UDP caso firewall/IDS degrade o tráfego UDP de RDP 8/10. |
Fluxo detalhado de solução
Investigar mensagens nos logs antes de qualquer mudança
Abra o Event Viewer e filtre os diretórios citados na matriz. Anote o DisconnectReason e o DiagnosticCode. Se aparecer 0xC000006D, concentre-se em autenticação – provavelmente o CredSSP falhou ou o usuário está bloqueado. Já 0xC000035B sinaliza falha de segurança durante a negociação do canal TLS, frequentemente causada por certificado expirado no Remote Desktop store.
Validar conectividade de rede fim a fim
Mesmo que a tela de logon apareça, a porta 3389 pode estar sendo reinicializada por IDS/IPS. Execute Test‑NetConnection -ComputerName servidor -Port 3389 -InformationLevel Detailed a partir de outra máquina no mesmo segmento. Pings intermitentes, jitter acima de 30 ms ou fragmentação de pacotes sugerem ajustar MTU ou desabilitar jumbo frames no vSwitch.
Descartar gargalos de CPU, RAM e disco
No Task Manager selecione a aba Users; você verá tentativas de sessões “Disc” ou “Down” com poucos segundos de duração. Ao mesmo tempo, observe se o gráfico de CPU bate 100 % quando o processo svchost.exe ‑k NetworkService dispara. Em servidores com 8 vCPU e 4 GB de RAM, atualizar para 8 GB é simples de dentro do vSphere e elimina esse gargalo.
Checar políticas de grupo locais e herdadas
Abra o gpresult /h c:\gp.html e revise o relatório. Configurações como “Set time limit for active but idle Remote Desktop Services session” ou “Require use of specific security layer for Remote (SSL)” herdadas de uma OU antiga podem entrar em conflito após um patch de segurança. Remova a vinculação ou coloque o servidor em uma OU de teste para confirmar.
Testar sem Network Level Authentication
NLA é excelente para proteger contra man‑in‑the‑middle, mas depende de CredSSP e de um certificado válido. Desative temporariamente a opção em System Properties ▸ Remote. Se a sessão passar a ficar estável, renove o certificado em MMC ► Certificates (LocalComputer) ► Remote Desktop ou reconfigure o template no AD CS.
Conferir licenciamento de RDS
Abra o Remote Desktop Licensing Diagnoser. Se vir o alerta “The remote session was disconnected because there are no Remote Desktop License Servers available”, configure novamente as chaves via gpedit.msc ou o Server Manager. Em laboratórios, o período de graça de 120 dias expira sem aviso visível ao administrador.
Atualizar VMware Tools e drivers
Driver VMXNET3 anterior à versão 18 apresentou bugs em que o buffer de recepção era zerado sob alto throughput, derrubando pacotes do protocolo RDP que viaja encapsulado em TCP e UDP. Atualizar as VMware Tools força a recompilação do driver e pode resolver na hora. Lembre‑se de reiniciar o guest após o update.
Desativar tráfego UDP como último recurso
Do Windows 8.1 em diante, o RDP usa UDP para melhorar latência. Firewalls empresariais que fazem deep packet inspection às vezes reagrupam pacotes, causando timeout. Criar a chave HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\fClientDisableUDP=1 obriga o cliente a trabalhar apenas em TCP. Teste e, se funcionar, investigue a política do IDS.
Dicas de mitigação rápida
- Acesso de console: abra o console direto no vSphere Web Client, iDRAC ou iLO para alterar políticas sem depender do RDP.
- Regra temporária de firewall: limite a porta 3389 ao seu endereço IP público enquanto o servidor está vulnerável sem NLA.
- Snapshot consciente: antes de aplicar hotfixes, tire snapshot e defina prazo para exclusão; snapshots longos aumentam o IO e podem travar a inicialização do serviço de terminal.
Boas práticas pós‑restauração
- Documente a causa raiz identificada (política, certificado, driver etc.) no Change Log do seu CMDB.
- Crie alerta no Event Log Forwarding para qualquer
DisconnectReasondiferente deBy User, enviando ao SIEM. - Automatize health checks diários via
Test-NetConnectionou script PowerShell que abra e feche rapidamente a porta 3389. - Revise a baseline de GPO a cada patch Tuesday, garantindo que atualizações de segurança não quebrem parâmetros TLS anteriormente válidos.
Conclusão
Uma sessão RDP que cai imediatamente raramente é obra de um único vilão. Geralmente é a interseção entre configuração de segurança, estado de recursos e atualizações de driver ou sistema. Seguindo a sequência logs ➔ rede ➔ recursos ➔ políticas ➔ NLA você isola a camada problemática em minutos, evita reinicializações desnecessárias e restabelece o acesso seguro ao Windows Server 2019.