Eu tenho um aplicativo de desktop remoto que foi publicado de uma empresa terceirizada para um de meus clientes. O aplicativo de área de trabalho remota se conecta a um Servidor Gateway de Área de Trabalho Remota (RDGW), que encaminha a solicitação a uma área de trabalho remota, onde o servidor menos utilizado responde à solicitação e abre o aplicativo. Isso funciona perfeitamente bem para a maioria dos cenários.
Hoje encontrei uma situação (digamos que o App foi publicado para um novo cliente), onde o RemoteApp solicitaria ao usuário suas credenciais (domínio \ nome de usuário e senha), logo após autenticar o usuário e aceitar o certificado para o RDS farm, mstsc.exe irá parar de funcionar, sendo totalmente não responsivo para cancelar ou fechar botões, e tem que ser terminado via gerenciador de tarefas.
Ao solucionar esse problema, descobri uma diferença na forma como o RemoteApp se conecta ao servidor Gateway de Desktop Remoto.
Em todos os meus cenários de testes positivos, o tráfego foi completamente encapsulado em HTTPS entre o meu MSTSC e o Gateway de Servidor de Área de Trabalho Remota da seguinte forma: 
Registrarotráfegoparaomesmoprocedimentoexatoemumdosmstsccomfalhamedeuisto:
A primeira conversa (como é chamada no NetMon) é a conexão HTTPS com o servidor RemoteDesktop Gateway (HTTPS, Porta 443), seguido por uma conexão RDP separada , que tenta se conectar ao RD servidor em si através do seu endereço IP privado (acabei de o anular na foto por motivos de privacidade e segurança). A segunda conexão eventualmente falha, porque o servidor RD não está no mesmo local / sub-rede, portanto, o endereço privado não é acessível para o mstsc.
Inicialmente, suspeitei do firewall do cliente, já que ele inspeciona o tráfego HTTPS, substituindo os certificados, para que ele possa interromper uma conexão HTTPS bem-sucedida com o servidor RDGW. Depois de desativar todas as funções do filtro da web no firewall, o problema ainda persiste. Eu também tentei rotear o tráfego através de um túnel OpenVPN, então ele ignora completamente o firewall, infelizmente sem sucesso.
O que poderia forçar o mstsc a não encapsular a conexão rdp no tráfego HTTPS como em uma conexão bem-sucedida? Isso é algum tipo de estratégia de fallback ou apenas um bug simples? E o que poderia ser usado como solução avançada de problemas para o aplicativo remoto, já que ele não possui arquivos de log valiosos e os servidores RDS e RDGW não estão sob meu controle?
EDIT (Adicionado arquivo de configuração anônimo):
redirectclipboard:i:1
redirectprinters:i:1
redirectcomports:i:0
redirectsmartcards:i:1
devicestoredirect:s:*
drivestoredirect:s:*
redirectdrives:i:1
session bpp:i:32
prompt for credentials on client:i:1
span monitors:i:1
use multimon:i:1
remoteapplicationmode:i:1
server port:i:3389
allow font smoothing:i:1
promptcredentialonce:i:0
videoplaybackmode:i:1
audiocapturemode:i:1
gatewayusagemethod:i:2
gatewayprofileusagemethod:i:1
gatewaycredentialssource:i:0
full address:s:INTERNAL-FQDN-SERVER-HOSTNAME.CUSTOMER.NET <!! EDITED FOR ANONYMIZE REASON
alternate shell:s:||name_of_remote_app_on_wts <!! EDITED FOR ANONYMIZE REASON
remoteapplicationprogram:s:||name_of_remote_app_on_wts <!! EDITED FOR ANONYMIZE REASON
remoteapplicationname:s:name_of_remote_app_on_wts <!! EDITED FOR ANONYMIZE REASON
remoteapplicationcmdline:s:
workspace id:s:INTERNAL-FQDN-SERVER-HOSTNAME.CUSTOMER.NET <!! EDITED FOR ANONYMIZE REASON
use redirection server name:i:1
loadbalanceinfo:s:tsv://MS Terminal Services Plugin.1.RemoteApp-EXT
alternate full address:s:INTERNAL-FQDN-SERVER-HOSTNAME.CUSTOMER.NET <!! EDITED FOR ANONYMIZE REASON
authentication level:i:2
prompt for credentials:i:0
negotiate security layer:i:1
gatewayhostname:s:external.gateway.ourcustomer.com <!! EDITED FOR ANONYMIZE REASON
signscope:s:Full Address,Alternate Full Address,Use Redirection Server Name,Server Port,GatewayUsageMethod,GatewayProfileUsageMethod,GatewayCredentialsSource,PromptCredentialOnce,Alternate Shell,RemoteApplicationProgram,RemoteApplicationMode,RemoteApplicationName,RemoteApplicationCmdLine,RedirectDrives,RedirectPrinters,RedirectCOMPorts,RedirectSmartCards,RedirectClipboard,DevicesToRedirect,DrivesToRedirect,LoadBalanceInfo
screen mode id:i:2
winposstr:s:0,3,0,0,800,600
compression:i:1
keyboardhook:i:2
connection type:i:7
networkautodetect:i:1
bandwidthautodetect:i:1
displayconnectionbar:i:1
enableworkspacereconnect:i:0
disable wallpaper:i:0
allow desktop composition:i:0
disable full window drag:i:1
disable menu anims:i:1
disable themes:i:0
disable cursor setting:i:0
bitmapcachepersistenable:i:1
audiomode:i:0
redirectposdevices:i:0
autoreconnection enabled:i:1
remoteapplicationicon:s:
shell working directory:s:
gatewaybrokeringtype:i:0
rdgiskdcproxy:i:0
kdcproxyname:s: