Windows Server 2019: corrigir “Please wait for the Remote Desktop configuration” (RDS/UPD)

Se o logon em um host RDS do Windows Server 2019 fica preso em “Please wait for the Remote Desktop configuration”, este guia explica a causa mais comum (User Profile Disks/UPD), como diagnosticar em minutos e as ações práticas para recuperar o ambiente com segurança.

Índice

Visão geral do problema

Em ambientes com Remote Desktop Services (RDS), é relativamente comum que, durante o logon, o utilizador veja a mensagem “Please wait for the Remote Desktop configuration” e a sessão nunca avance. Embora haja várias causas possíveis, a causa mais recorrente em coleções de Sessão é um problema com os User Profile Disks (UPD), que são arquivos .vhdx armazenados num compartilhamento SMB e anexados dinamicamente ao host de sessão no momento do logon.

O que acontece por baixo dos panos: o host tenta montar o VHDX do perfil do usuário a partir do caminho UNC configurado. Se o compartilhamento estiver lento, sem espaço, com permissões inadequadas, indisponível, ou se o VHDX estiver bloqueado/corrompido, a montagem falha ou fica em espera — e o logon fica travado.
Resultado visível: tela “Please wait for the Remote Desktop configuration” por minutos (ou indefinidamente), às vezes seguida de disconnect, volta à tela de credenciais, ou criação de perfil temporário quando há fallback.

Causa mais provável: User Profile Disks (UPD)

O UPD mantém o perfil do usuário num VHDX único por SID, normalmente com o padrão UVHD-<SID>.vhdx. Este arquivo vive num compartilhamento (por exemplo, \\filesrv\profiles$\UPD) e é anexado como disco virtual no host RDS a cada logon. Qualquer problema que impeça a leitura/escrita rápida e consistente deste arquivo pode travar o processo de logon, deixando a sessão presa na mensagem de configuração do RDP.

Gatilhos típicos:

Compartilhamento SMB indisponível ou intermitente (queda de rede, cluster em failover, problemas de DNS, ACLs de firewall).
Capacidade: volume do fileserver sem espaço livre suficiente; cotas rígidas.
Desempenho: latência elevada (picos de I/O, storage degradado, backup em execução com lock exclusivo).
Permissões inadequadas no share ou NTFS (hosts RDS sem acesso; deny acidental; herança quebrada).
VHDX bloqueado por sessão anterior, antivírus, agente de backup, indexador ou outro host; ou VHDX corrompido.

Como verificar rapidamente (checklist prático)

Confirmar se UPD está habilitado na coleção

Abra Gerenciador do Servidor → Serviços de Área de Trabalho Remota → Coleções.
Abra Propriedades da coleção e verifique se Discos de Perfil do Usuário está Habilitado.
Anote o caminho UNC do compartilhamento dos perfis (UPD).

Testar o compartilhamento/armazenamento do UPD

De outra máquina (ou de um host RDS), verifique conectividade, permissões e capacidade:

$share = '\\filesrv01\UPD$'

Acessibilidade básica

Test-Path \$share

Latência e porta SMB (445)

Test-NetConnection -ComputerName filesrv01 -Port 445

Tentativa de criar e apagar um ficheiro de teste

New-Item -Path (Join-Path \$share 'teste.txt') -ItemType File -Force
Remove-Item (Join-Path \$share 'teste.txt') -Force

Conexões SMB ativas

Get-SmbConnection -ServerName filesrv01

Se possível, verifique espaço livre no servidor de arquivos (ajuste o DeviceID ao volume real):

Get-CimInstance -ClassName Win32_LogicalDisk -ComputerName filesrv01 -Filter "DeviceID='D:'" |
  Select-Object DeviceID, @{N='FreeGB';E={[math]::Round($.FreeSpace/1GB,2)}}, @{N='SizeGB';E={[math]::Round($.Size/1GB,2)}}

Problemas comuns aqui: timeout ao listar o diretório, erro de acesso negado, escrita falhando ou espaço livre muito baixo (< 10% em volumes com picos de I/O costuma ser arriscado).

Rever os logs de eventos

Abra o Visualizador de Eventos e verifique:

Microsoft‑Windows‑User Profile Service (falhas ao carregar/montar o perfil ou o VHDX).
Microsoft‑Windows‑RemoteDesktopServices‑RdpCoreTS e LocalSessionManager (erros na iniciação de sessão, desconexões, timeouts).
Microsoft‑Windows‑SMBClient/SMBServer (quedas, timeouts, acessos negados, bloqueios persistentes).

Registre códigos/IDs e mensagens. Eles ajudam a mapear erro → causa → ação e aceleram a correção e a prevenção.

Checar se há VHDX preso ou bloqueado

No servidor de arquivos, liste arquivos .vhdx abertos e feche com segurança, se for o caso (apenas quando tiver certeza de que a sessão foi encerrada):

Get-SmbOpenFile | Where-Object { $_.Path -like '*.vhdx' } | 
  Select-Object SessionId, ClientComputerName, Path, FileId, Locks

Fechar um handle específico (cuidado!)

Close-SmbOpenFile -FileId \<Id> -Force

No host de sessão, confirme se o VHDX está anexado (ou com estado inconsistente):

Get-DiskImage -ImagePath '\\filesrv01\UPD$\UVHD-S-1-5-21-...\UVHD-SID.vhdx' -ErrorAction SilentlyContinue

Testar logon sem UPD

Como prova de causa, desative temporariamente o UPD na coleção (ou via GPO) e tente o logon com o mesmo usuário. Se o logon funcionar de imediato, a causa está no armazenamento/permissões do UPD ou no VHDX específico.

Ações de correção (do mais comum ao mais efetivo)

Restabelecer o compartilhamento: recuperar conectividade SMB, corrigir DNS, remover bloqueios, garantir capacidade (libere espaço >= 10–20%), e revisar permissões NTFS/Share de forma que os hosts RDS e o usuário possam ler/gravar sem heranças confusas.
Reiniciar serviços do RDS no host de sessão para limpar estados presos (preferencialmente fora do horário de pico): Restart-Service -Name TermService -Force Restart-Service -Name UmRdpService -Force
Desanexar/recuperar VHDX problemático: confirme que não há sessão ativa, desmonte o VHDX no host que o mantém. Se suspeitar de corrupção, monte em read-only para validar e tentar reparos: Mount-VHD -Path '\\filesrv01\UPD$\UVHD-SID.vhdx' -ReadOnly Se montar, será atribuído um volume (letra de unidade). Avalie integridade. CHKDSK (executar com cautela; preferencialmente numa cópia): chkdsk X: /scan Dismount-VHD -Path '\\filesrv01\UPD$\UVHD-SID.vhdx' Se estiver de facto corrompido, crie um novo perfil (novo VHDX) e migre dados (Documentos, Desktop, AppData relevante) do VHDX antigo montado em modo somente leitura, quando possível.
Reinicialização controlada do host de sessão pode destravar estados residuais, mas trate como paliativo; investigue e elimine a causa raiz para não voltar a ocorrer.
Monitorar os logs após a correção para confirmar montagem do UPD sem erros e queda nos eventos de falha/timeout.

Se você não usa UPD: outras causas e como isolar

Conectividade com Controlador de Domínio/DNS (inclui sincronização de hora). Sem DC, o Kerberos e o carregamento de perfil podem falhar. Verifique: nltest /dsgetdc:<SEU_DOMÍNIO> w32tm /query /status ipconfig /all No PowerShell, valide o canal seguro: Test-ComputerSecureChannel -Verbose
Perfil local corrompido: teste com outro usuário. Para o usuário afetado, renomeie o diretório em C:\Users<usuario> e a chave de perfil (após backup), deixando o Windows recriar: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList<SID>
Serviços RDS desatualizados ou pendentes de reinício após atualizações cumulativas.
Scripts de logon/GPO que bloqueiam a sessão (mapeamentos lentos, drivers de impressora problemáticos, políticas contraditórias).
Antivírus/EDR inspecionando intensamente diretórios de perfil (ou VHDX), causando atrasos. Considere exclusões específicas.
FSLogix (se usado em vez de UPD): a lógica é semelhante — verifique a partilha, permissões e registos do agente FSLogix; containers presos/críticos causam sintomas parecidos.

Indicadores fortes da causa raiz

Timeout/intermitência ao acessar o caminho UNC do perfil (listar diretório já é lento).
Eventos explícitos de erro ao anexar/montar o VHDX nos canais do User Profile Service e do SMB.
Logon funciona quando o UPD é desativado ou quando se usa um perfil novo de teste.

Playbook de emergência (para restaurar acesso rapidamente)

Escolha um host RDS de manutenção e redirecione novas sessões para outro (limite de conexões/Drain Mode).
Teste o share do UPD (latência, espaço, permissões). Corrija o que estiver errado.
Se apenas alguns usuários forem afetados, rename o respectivo VHDX para .bak e deixe o sistema gerar um novo; depois migre dados.
Se todos estiverem afetados, desative o UPD temporariamente na coleção e comunique que os perfis poderão ser temporários. Enquanto isso, resolva a causa no armazenamento.
Reinicie TermService e UmRdpService no(s) host(s) afetado(s) para limpar handle/estado.
Habilite novamente o UPD e valide com um grupo piloto antes de liberar a todos.

Tabela de diagnóstico rápido

Verificação	Como fazer	Resultado esperado	Se falhar…
Acesso ao share	`Test-Path \\servidor\share`	True e listagem imediata	Rede/DNS/Firewall/ACLs
Latência SMB	`Test-NetConnection -Port 445`	Latency baixa e TCP aberto	Rota/Storage saturado
Escrita	Criar/Apagar ficheiro teste	Sem erro e imediato	Permissões, cota, AV/Backup
Espaço livre	Consultar volume no fileserver	>= 10–20% livre	Limpeza/Expansão de volume
VHDX aberto	`Get-SmbOpenFile`	Sem locks inesperados	Feche handle seguro
Logs do perfil	Event Viewer → User Profile Service	Sem erros recentes	Tratar causa reportada
Prova sem UPD	Desabilite UPD e tente logon	Logon completo	Foco no armazenamento/UPD

Boas práticas para evitar recorrência

Planeamento de capacidade: mantenha margens confortáveis de espaço e IOPS no volume do UPD; monitore crescimento (novos usuários, apps que aumentam AppData).
Monitorização contínua:
- Alertas de espaço livre (< 15% → alerta; < 10% → crítico).
- Erros/avisos nos canais de SMBClient/Server e User Profile Service.
- Tempo médio de logon por coleção (picos podem indicar problemas de storage/GPO).
Exclusões no antivírus/backup para diretório do UPD e extensão .vhdx (leitura sem lock). Valide boas práticas do seu fornecedor.
Padronize permissões no share/NTFS, evitando herança inesperada; documente a DACL efetiva.
Ciclos de manutenção: feche sessions órfãs, remova VHDX antigos de usuários desligados, e limpe perfis temporários.
Testes de mudança: antes de atualizações de SO/driver/storage, execute um piloto e valide tempo de logon, montagem do UPD e integridade.
Considerar FSLogix para cenários modernos (quando aplicável), avaliando requisitos e suporte — o conceito de container é similar, mas com melhorias de perfil e cachê.

Exemplos de comandos úteis (cole & use conforme seu cenário)

Rede e SMB

# Verificar rota/latência até o fileserver
Test-Connection filesrv01 -Count 4

Porta 445 aberta?

Test-NetConnection filesrv01 -Port 445

Sessões SMB do host atual

Get-SmbSession

Conexões SMB específicas a um servidor

Get-SmbConnection -ServerName filesrv01

Permissões e arquivos abertos no servidor de arquivos

# Arquivos VHDX abertos (locks)
Get-SmbOpenFile | Where-Object { $_.Path -like '\UVHD-.vhdx' } |
  Format-Table -Auto Size,ClientComputerName,Path,FileId,Locks

(Cuidado) Fechar handle específico

Close-SmbOpenFile -FileId \<Id> -Force

Serviços RDS

# Estado
Get-Service TermService, UmRdpService

Reiniciar (fora de pico)

Restart-Service TermService -Force
Restart-Service UmRdpService -Force

Perfil local e chaves

# Listar perfis locais
Get-CimInstance Win32_UserProfile | Select-Object LocalPath, SID, Loaded

(Avançado) Renomear diretório de perfil e limpar chave do SID (faça backup antes)

Caminho da chave:

HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList&lt;SID>

FAQ (perguntas que surgem no dia a dia)

1) Reiniciar o host sempre resolve?
Ajuda a limpar estados presos e locks, mas se a causa for armazenamento/permite-se, o problema retornará. Use a reinicialização como último recurso e foque na causa raiz.

2) Posso apagar o VHDX problemático?
Não apague sem backup. Renomeie para .bak, gere um novo perfil e, se possível, migre dados do VHDX antigo montado em modo somente leitura. A exclusão direta pode causar perda de dados e chamados de recuperação.

3) O travamento acontece apenas com alguns usuários. O que indica?
Tende a indicar VHDX específico preso ou corrompido, ou permissões individuais incorretas naquele arquivo. Em geral, o storage em si está funcional.

4) Com todos os usuários afetados de uma vez, o que priorizar?
Conectividade/saúde do compartilhamento (rede, DNS, ACLs, espaço), depois latência do storage. Desabilitar temporariamente o UPD pode restabelecer a operação enquanto corrige-se a causa.

5) Desativar o UPD faz perder dados?
Não elimina o VHDX existente. Apenas usa um perfil alternativo (local/temporário) durante o teste. Ao reativar, a montagem volta a ocorrer, desde que a causa original esteja resolvida.

Resumo executivo

Para o sintoma “Please wait for the Remote Desktop configuration” no Windows Server 2019, em ambientes RDS, a raiz mais comum é UPD com problemas (compartilhamento indisponível/lento, falta de espaço, permissões, VHDX bloqueado/corrompido). O diagnóstico rápido consiste em confirmar o uso de UPD, testar o share (acesso, latência, escrita, capacidade), revisar eventos (User Profile Service, RdpCoreTS, LocalSessionManager, SMB), checar locks e, como prova, tentar logon com UPD desativado. A correção passa por restabelecer a partilha, liberar espaço, ajustar permissões, reiniciar serviços, recuperar ou recriar VHDX e monitorar os eventos para validar a normalização. Se UPD não estiver em uso, verifique DC/DNS/hora, integridade do perfil local e serviços/GPOs.

Dica adicional: padronize o registo dos IDs e mensagens de evento encontrados em cada incidente e mantenha um guia interno mapeando erro → causa → ação. Isso encurta drasticamente o MTTR em ocorrências futuras.