MENU
  1. Início
  2. Windows
  3. RDP
  4. RD Web e RemoteApp no Servidor B no Windows Server: como corrigir “program not in the list of authorized programs” e falhas RDP 3389

RD Web e RemoteApp no Servidor B no Windows Server: como corrigir “program not in the list of authorized programs” e falhas RDP 3389

RDP

As apps do RD Web iniciam no Servidor A mas falham no Servidor B? Este guia prático reúne sintomas, causas prováveis e um passo a passo validado em campo para restaurar a abertura de RemoteApps a partir do segundo Session Host, com foco em Windows Server e RDS.

Índice

Contexto e sintomas

  • Arquitetura: dois servidores de Sessão RD (A e B).
  • Funções:
    • Servidor A: RD Connection Broker, RD Session Host e RD Web Access.
    • Servidor B: apenas RD Session Host.
  • O que funciona: RemoteApps publicadas no Servidor A abrem normalmente pelo RD Web.
  • O que falha: RemoteApps do Servidor B apresentam erros como:
    • “Windows cannot start the remote program. The following RemoteApp program is not in the list of authorized programs.”
    • “Remote Desktop can’t connect to the computer…”

Por que o Servidor B falha no RD Web

Na maioria dos ambientes, o RD Web enumera programas a partir do Connection Broker. Se uma RemoteApp do Servidor B não estiver associada a uma coleção que o Broker publica, ou se o host não estiver alcançável na porta de RDP, o lançamento falha. Outras causas recorrentes incluem IPv6 mal configurado, Desktop Remoto desativado ou escuta em porta diferente da 3389, e regras de firewall incompletas.

Causa provávelSinais típicosComo confirmarCorreção rápida
Programa do Servidor B não reconhecido pelo BrokerErro “program not in the list of authorized programs”Ver se existe RemoteApp na coleção e se a coleção inclui o Servidor BAtribuir a RemoteApp à coleção correta e republicar
Porta RDP 3389 bloqueada ou NAT incorretoErro de conexão RDP genérico, timeoutTest-NetConnection ServidorB -Port 3389Abrir 3389 no firewall local e na rede
IPv6 mal negociadoConexão intermitente apenas via RD WebQueda quando a pilha tenta IPv6 primeiroDesativar temporariamente IPv6 para teste
Remote Desktop desativado ou porta alteradaSem serviço de escutanetstat -an | findstr :3389Reativar Desktop Remoto ou reconfigurar a porta

Diagnóstico rápido inicial

  1. Teste RDP direto: no seu computador de administração, abra mstsc.exe e conecte em ServidorB (ou FQDN) usando /admin. Se não conectar de forma alguma, o problema é rede/serviço, não RD Web.
  2. Teste de porta: Test-NetConnection ServidorB -Port 3389 ou: telnet ServidorB 3389 no próprio Servidor B: netstat -an | findstr :3389
  3. Reativação do Desktop Remoto (força recriação de ACLs e regras padrão): # Executar no Servidor B (PowerShell elevado) Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server' -Name fDenyTSConnections -Value 1 Restart-Service -Name TermService -Force Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server' -Name fDenyTSConnections -Value 0 Enable-NetFirewallRule -DisplayGroup 'Área de Trabalho Remota'
  4. Desativação de IPv6 para teste: # Desativa o binding IPv6 no(s) adaptador(es) (reversível) Get-NetAdapter | ForEach-Object { Disable-NetAdapterBinding -Name $.Name -ComponentID mstcpip6 -PassThru } Restart-Computer Reativar depois do teste: Get-NetAdapter | ForEach-Object { Enable-NetAdapterBinding -Name $.Name -ComponentID mstcpip6 -PassThru } Nota: Em ambientes com IPv6 operacional, prefira corrigir roteamento/DNS em vez de manter IPv6 desativado.
  5. Validação de coleção e RemoteApps: # No Broker (ou servidor com as ferramentas RDS) Import-Module RemoteDesktop Get-RDServer Get-RDSessionCollection Get-RDSessionHost -CollectionName 'NomeDaColecao' Get-RDRemoteApp -CollectionName 'NomeDaColecao' | Select Alias,DisplayName,FilePath Confirme se o Servidor B consta como SessionHost da coleção e se a RemoteApp que falha existe nessa coleção.

Soluções sugeridas no fórum e por práticas de campo

NºAçãoObjetivoComando rápido
1Reativar o Remote Desktop: desligar, reiniciar, voltar a ligarRecriar ACLs e serviços associadosSet-ItemProperty ... fDenyTSConnections + Restart-Service TermService
2Desativar IPv6 no testeForçar tráfego apenas por IPv4 e evitar quedas no handshakeDisable-NetAdapterBinding -ComponentID ms_tcpip6
3Abrir a porta 3389 no Windows Defender Firewall (Perfis Privado e Público)Permitir que clientes e o Broker cheguem ao Servidor BEnable-NetFirewallRule -DisplayGroup 'Área de Trabalho Remota'
4Confirmar escuta na 3389Garantir serviço RDP ativonetstat -an | findstr :3389 ou Get-NetTCPConnection -LocalPort 3389
5Rever coleções e RemoteApps no Server ManagerEvitar “program not in the list of authorized programs”Get-RDSessionCollection / Get-RDRemoteApp
6Consultar o guia oficial de resolução de problemas de RDP no Windows ServerChecklist de diagnóstico adicionalReferência na documentação do fabricante

Resolução aprofundada

Coleções e RemoteApps

O RD Web só lista e inicia programas que o Connection Broker reconhece. Se o atalho do RD Web aponta para um Alias que não existe na coleção do Servidor B, o lançamento falha com a mensagem de programa não autorizado.

  1. No Server Manager do Broker: Remote Desktop Services → Collections. Abra a coleção que deverá conter as apps do Servidor B.
  2. Confirme:
    • Session Hosts: o Servidor B aparece listado.
    • RemoteApps: a aplicação problemática aparece, com path válido no Servidor B.
    • Usuários/grupos autorizados: o grupo de utilizadores tem permissão na coleção.
  3. Se faltar algo:
    • Adicione o Servidor B como Session Host da coleção.
    • Publique a RemoteApp apontando para o executável presente no Servidor B.
    • Sincronize as pastas/versões do aplicativo entre A e B (caminho idêntico ajuda muito).

Dica: em ambientes híbridos, mantenha o mesmo FilePath e o mesmo Alias de RemoteApp em todos os hosts que farão parte da coleção.

Connection Broker e RD Web

  • Garanta que o RD Web Access aponta para o Broker correto.
  • Verifique se o computador do RD Web está no grupo de segurança que tem permissão para ler apps do Broker (por exemplo, TS Web Access Computers em ambientes com diretório).
  • Em topologias com Gateway, valide as políticas CAP e RAP, garantindo acesso ao Servidor B.

Rede e firewall

Mesmo com RemoteApp publicada, sem a porta 3389 aberta o lançamento não ocorre. Verifique:

  • Firewall local: regras do grupo Área de Trabalho Remota ativas para os perfis Privado e Público.
  • Firewall de perímetro: fluxo da 3389 entre clientes/Broker e o Servidor B.
  • NAT: mapeamentos corretos quando acessado de fora. Não reutilize o mesmo IP público para hosts diferentes sem regras específicas.
# PowerShell no Servidor B
Get-NetFirewallRule -DisplayGroup 'Área de Trabalho Remota' | Format-Table Name, Enabled, Profile

De um cliente ou do Broker

Test-NetConnection ServidorB -Port 3389 -InformationLevel Detailed

IPv6 e pilha de rede

Alguns ambientes com IPv6 parcialmente configurado apresentam falhas intermitentes quando o cliente tenta negociar via IPv6. Para isolar:

  • Teste com IPv6 desativado temporariamente (conforme exemplo anterior).
  • Se resolver, corrija DNS, roteamento ou prefixos IPv6; em último caso, mantenha IPv4 apenas, com a devida governança.

Desktop Remoto desativado ou porta alterada

Se alguém mudou a porta do RDP, o RD Web não alcançará o host na 3389.

# Ver porta configurada (decimal)
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name PortNumber

Voltar para 3389 (requer janela de manutenção)

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name PortNumber -Value 3389
Restart-Service -Name TermService -Force

Ativar Desktop Remoto pela interface: Configurações → Sistema → Área de Trabalho Remota (ou Painel de Controlo → Sistema em versões mais antigas). Em ambientes com Políticas de Grupo, valide as definições de Allow users to connect remotely using Remote Desktop Services.

Certificados e assinatura

  • Verifique o certificado do RD Web e do Broker: CN/SAN correspondendo ao FQDN exposto, cadeia confiável e validade em dia.
  • Nos hosts, confira o certificado do ouvinte RDP (RDP-Tcp). Certificados expirados ou autoassinados podem causar avisos e, em alguns clientes, bloqueio.
# Listar certificados locais (exemplo)
Get-ChildItem Cert:\LocalMachine\My | Select Subject, NotAfter, Thumbprint

Grupos de segurança e permissões

  • Sincronize grupos de acesso da coleção com os grupos de utilizadores que realmente lançarão as apps.
  • Adicione os servidores apropriados a grupos como TS Web Access Computers, se a política restringir a leitura das publicações.
  • Confirme que o RD Session Host B tem permissão de conexão para os utilizadores/grupos definidos (política local ou GPO).

Registos de eventos que ajudam

Ative e consulte os registos especializados do RDS para encontrar o ponto exato da falha.

  • Event Viewer → Applications and Services Logs → Microsoft → Windows → RemoteDesktopServices-*
  • Fontes úteis:
    • RdpCoreTS e RemoteConnectionManager: negociações de sessão e TLS.
    • SessionServices e RDMS: coleção e publicação.
# Exemplos de consultas
Get-WinEvent -LogName 'Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational' -MaxEvents 50 |
  Select TimeCreated, Id, LevelDisplayName, Message

Get-WinEvent -LogName 'Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational' -MaxEvents 50 |
Select TimeCreated, Id, Message

Dica: eventos como 164, 227, 140 e 1012 frequentemente apontam a raiz do problema (por exemplo, falha de autenticação, limitação de coleção, serviço não escutando, publicação inexistente).

Balanceamento de carga e DNS

  • Se houver round‑robin DNS ou NLB, verifique se o FQDN usado pelo RD Web resolve para o Servidor B quando apropriado.
  • Respeite TTLs e limpe entradas antigas quando retirar um host de manutenção.
  • Garanta que o Broker conhece todos os IPs atribuídos e que o drain mode não ficou ativo por engano no Servidor B.
# Verificar / ajustar modo de dreno (no Broker)
Get-RDSessionHost -CollectionName 'NomeDaColecao' | Select SessionHost, NewConnectionAllowed
Esperado: NewConnectionAllowed = Yes

Perguntas frequentes

É preciso abrir a 3389 em todos os Session Hosts? Sim. Cada host que receberá sessões RDP deve aceitar conexões na 3389 (ou na porta configurada) a partir do Broker, clientes internos e/ou Gateway, conforme a topologia. Em redes expostas à internet, não publique a 3389 diretamente; utilize RD Gateway.

Estudo prático

Ambiente com A e B; apps no A funcionavam, apps no B falhavam com “program not in the list of authorized programs”. Verificação mostrou que o Servidor B não constava como Session Host da coleção “Prod”. Após adicioná‑lo à coleção, republicar as RemoteApps e abrir a 3389 no firewall do B, o RD Web passou a iniciar as aplicações normalmente.

Apêndice de comandos úteis

# Listar hosts de sessão por coleção
Import-Module RemoteDesktop
Get-RDSessionCollection | Format-Table CollectionName, CollectionType
Get-RDSessionHost -CollectionName 'Prod' | Format-Table SessionHost, NewConnectionAllowed

Adicionar o Servidor B à coleção (executar no Broker)

Add-RDSessionHost -CollectionName 'Prod' -SessionHost 'ServidorB.dominio.local'

Publicar uma RemoteApp (exemplo)

New-RDRemoteApp -CollectionName 'Prod' -DisplayName 'Bloco de Notas' -FilePath 'C:\Windows\System32\notepad.exe' -Alias 'notepad'

Ver escuta e estado do serviço

Get-Service TermService
Get-NetTCPConnection -LocalPort 3389

Testes de rede

Resolve-DnsName ServidorB
Test-NetConnection ServidorB -CommonTCPPort RDP -InformationLevel Detailed

Boas práticas adicionais

  • Mantenha caminhos de instalação idênticos da aplicação entre os hosts da mesma coleção.
  • Padronize Aliases de RemoteApp e nomes de exibição.
  • Automatize validações pós‑mudança com um script de smoke test que faça Test-NetConnection, verifique escuta na 3389 e confirme a presença das RemoteApps.
  • Renove certificados com antecedência e instale‑os no Broker, Web e nos listeners dos Session Hosts.
  • Implemente RBAC e GPOs para impedir alterações acidentais na porta RDP e nas regras de firewall.

Correção para o caso fora de escopo de web local na porta oito mil

O comentário citado sobre “page not working” em 127.1.1.1:8000 refere‑se a um serviço web local, não a Remote Desktop Services. O problema típico envolve o processo de desenvolvimento não iniciado, firewall local a bloquear a 8000, ou o serviço a escutar noutra interface.

  • Endereço de escuta: muitos servidores de desenvolvimento escutam por padrão em 127.0.0.1. Se chamou 127.1.1.1, pode não haver binding. Use 127.0.0.1:8000 ou localhost:8000 ou configure para 0.0.0.0 quando apropriado.
  • Validação rápida: netstat -ano | findstr :8000 ou no PowerShell: Get-NetTCPConnection -LocalPort 8000
  • Exemplos:
    • Django: python manage.py runserver 127.0.0.1:8000
    • Node/NPM: npm run dev -- --host 127.0.0.1 --port 8000

Resumo prático

  1. Habilite e valide a conectividade RDP ao Servidor B na 3389.
  2. Teste com IPv6 desativado temporariamente ou corrija a pilha IPv6.
  3. Confirme que as RemoteApps do Servidor B pertencem a uma coleção publicada pelo Broker e que o host está listado como Session Host.
  4. Revise certificados do RD Web/Broker e pertenças a grupos de segurança.
  5. Use os registos do RDS para identificar o ponto de falha e ajuste balanceamento/DNS quando houver.

Seguindo esse roteiro, a maioria dos ambientes volta a iniciar corretamente as aplicações publicadas no segundo Session Host via RD Web.

RDP
Connection Broker Firewall IPv6 RD Web RDP 3389 RemoteApp Windows Server
Índice