A área de trabalho remota funciona apenas com clientes antigos

Todos os computadores com Windows 8.1 recusam repentinamente as conexões da Área de Trabalho Remota.

O problema é quando nos conectamos TO do Windows 8.1
Não temos o problema ao se conectar a outras versões do Windows.

edit: problema resolvido com a atualização KB2962806 da Microsoft. Agradeço a Bertrand SCHITS pela resposta.

O que encontramos até agora:

• sempre podemos nos conectar como um usuário local. O problema é apenas para usuários do domínio (administrador e regular)
• podemos nos conectar com versões antigas do mstsc.exe. Por exemplo, podemos conectar-se a partir de computadores Windows 2003 e 2003 R2. Não podemos nos conectar a partir do Windows 7, Windows 8.1 e Windows 2012 R2.
  Se copiarmos o antigo mstsc.exe (versão 5.2.xxxx) do Windows 2003 para um computador mais recente, podemos conectar
• se nos conectarmos a partir de uma versão antiga do mstsc.exe (como mencionado acima), por alguns minutos, podemos nos conectar a partir de qualquer versão que desejar. Devemos usar a versão antiga novamente após um período aleatório de tempo (de 30 segundos a várias horas)
• com as versões recentes do mstsc.exe, em algum momento não podemos conectar alguns usuários, mas isso funciona com outros usuários. Esse comportamento desaparece assim que usamos uma versão antiga e pode reaparecer 2 dias depois
• (graças à resposta de Warren) se adicionarmos manualmente enablecredsspsupport:i:0ao arquivo .rdp, as credenciais não serão solicitadas antes da conexão (portanto, o comportamento é o mesmo que com os clientes antigos) e podemos conectar- nos a qualquer versão do cliente. Mas não podemos conectar-se automaticamente, e o processo de login envolve cada vez que você escolhe fazer logon como outro usuário (mesmo que seja o mesmo usuário)
• (graças a Pathum Anjana) aplicamos a atualização opcional KB2830477 nos dois lados das conexões

O que testamos:

• testamos da rede local para o local e do distante para o local. Sem diferença
• nós desativamos o firewall
• testamos a desativação de todos os recursos de segurança com o gpedit.msc Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Security
• ativamos a auditoria para eventos de logon e nada nos logs. Nada óbvio em outros logs (como habilitar os logs do protocolo RDP?)
• testamos em um computador localizado em outra rede (os domínios não estão relacionados), que possui apenas 7-zip instalado. Sem drivers de impressora, sem diretivas de grupo e nada mais. É apenas um novo Windows 8.1 atualizado. Temos exatamente o mesmo problema
• perguntamos ao Google e ele disse "eu realmente não sei". Ele agora nos direciona para esta página, que é uma resposta muito boa, mas não é realmente útil
• removemos todas as atualizações até 25 de fevereiro (vários dias antes do problema). Nenhuma melhoria, portanto, o problema pode ser uma configuração existente configurada para um valor diferente por uma atualização recente (e não revertida quando a atualização é removida, o que provavelmente é o comportamento usual)

Quando não conseguimos conectar, a mensagem de erro é exatamente a mesma que recebemos com uma senha incorreta (mas nenhuma entrada no log de segurança):

• todo computador tem licenças válidas
• usamos o MSE como antivírus
• alguns Windows 8.1 são pré-instalados pelo fabricante (Lenovo), enquanto outros são instalados por nós. O único fator comum que vejo é o fato de gerenciarmos todos eles

Alguma idéia do que podemos fazer para resolver esse problema?

Talvez isso esteja relacionado ao KB2962806. Você deve tentar aplicá-lo.
Não sei como aplicar esta atualização porque ela não está disponível no site da Microsoft. Só o recebo com a atualização automática do Windows, mas não em todos os computadores.

Esta atualização resolveu um problema semelhante para mim. E como essa atualização é aplicada em ALGUNS computadores, todos os outros também funcionam. Eu não procurei o porquê.

O prompt de credenciais me deixou louco nos últimos dias e, seguindo a cadeia de eventos recentes, acredito que esteja relacionado ao KB3035017 que nossos servidores RDP 2012 instalaram recentemente.

Depois de pesquisar este e outros posts, encontrei algo que até agora está solucionando o problema.

Testar ícones RDP do meu lado na mesma máquina gera um erro de prompt de credenciais, um, e login bem-sucedido, por outro.

http://www.boredsysadmin.com/2008/06/how-to-disable-credentials-prompt-of.html

Espero que isso ajude outras pessoas, continuarei monitorando e procurando uma correção correta.

Felicidades

Provavelmente funciona com os clientes RDP mais antigos, porque força um downgrade da versão do protocolo, onde qualquer problema causa isso não ocorre.

Meu palpite é que isso pode estar relacionado à resolução da tela. A Microsoft fez algumas alterações relacionadas à resolução da tela e manipulação de vários monitores no RDP no Windows 8.1. Embora seus sintomas não pareçam estar relacionados a resoluções, talvez a negociação falhe entre o cliente RDP do Windows 7 e o Windows 8.1?

Isso também explicaria por que funciona para alguns usuários e não para outros - eles podem ter configurações de resolução diferentes no cliente ou no sistema 8.1 de destino.

Veja se alterar a resolução da tela no cliente RDP tem algum efeito (em particular, alterar entre o modo de tela cheia e uma resolução específica e também alterar as configurações de vários monitores).

Você pode ler mais sobre isso aqui: http://blogs.msdn.com/b/rds/archive/2013/12/16/resolution-and-scaling-level-updates-in-rdp-8-1.aspx

Dado o tempo que você está vendo, o problema pode coincidir com o patch para CVE-2015-0079 . O boletim da Microsoft relacionado a esta vulnerabilidade é MS15-030 e o patch real para o problema está disponível aqui . Se esse patch foi instalado em seus sistemas, tente removê-lo de um deles para ver se isso faz com que o problema desapareça.

Não seria o primeiro patch da Microsoft a quebrar certas combinações de RDP. Dê uma olhada nisso - em particular sobre o KB2984972.

O problema que a Microsoft está corrigindo com o patch é um possível ataque de negação de serviço - geralmente não muito problemático em um ambiente de escritório, mas ainda assim.