Um farm de servidores de área de trabalho remota que funcionava bem parou de funcionar há dois dias. A configuração é a seguinte:
- O DNS resolve "myfarm.mydomain.local" para os IPs de todos os servidores membros do farm
- Todos os servidores membros do farm são configurados como membros do farm "myfarm" no Broker MYBROKER
- Todos os membros do farm são membros do grupo de corretores de sessão local no MYBROKER
- Os clientes são configurados para se conectar a "myfarm"
(Todos os servidores envolvidos são caixas Windows2008R2 virtuais). De repente, as pessoas começaram a receber o seguinte erro (traduzido do alemão) e não conseguiram se conectar.
Não é possível conectar ao servidor de terminal.
O farm de servidores de terminal "myfarm" ao qual você está tentando se conectar está redirecionando você para o servidor "farmmemberX.mydomain.local". A área de trabalho remota não pode verificar se este servidor pertence ao mesmo farm de servidores. Isso pode ocorrer se houver um servidor em sua rede com o mesmo nome do farm de servidores. ?Não pode ser verificado se ambos os computadores remotos pertencem ao mesmo farm de servidores de área de trabalho remota. Você deve usar o nome do farm, não o nome do computador, se quiser fazer uma conexão com um farm de servidores de área de trabalho remota.
Entre em contato com um administrador de rede para obter suporte se você usar uma conexão RDP preparada pelo administrador.
Se você deseja se conectar com um membro específico do farm, use "mstsc /admin"
Às vezes, parecia também que eles foram simplesmente rejeitados como se tivessem inserido credenciais erradas (o que eles não fizeram, a maioria salvou suas credenciais)
Questão 1. Você pode explicar o que está por trás disso, especificamente em relação ao "não pôde ser verificado": Como ocorre essa verificação se funciona? Afinal, o redirecionamento nem seria tentado se não fosse iniciado pela corretora...
O que tentamos: às vezes, ajudava substituir o nome ao qual o cliente se conecta por outra coisa (ou seja, adicionamos um nome "foo" ao DNS que resolvia para os mesmos IPs e fazia com que os usuários se conectassem a "foo"), mas isso estava longe de consistente.
Mais tarde, notamos que sempre os mesmos poucos servidores apareciam como "farmmemberX" na mensagem de erro acima. Nós os removemos experimentalmente do farm (nos próprios membros e no DNS) e assim conseguimos reduzir o farm quebrado de oito servidores para um farm funcional de dois servidores. Como isso não seria suficiente para reduzir a carga do usuário, eu queria clonar um deles; para fazer isso, primeiro desliguei e depois reiniciei - a partir do momento em que ficou tão ruim quanto os outros seis servidores. Aparentemente , reiniciar os servidores RDP foi a coisa fatal a se fazer ... De acordo com os logs, esse servidor em particular não foi reiniciado por cerca de dois meses. Portanto, praticamente qualquer mudança feita nos últimos dois meses pode ser relevante. Entre estes estão
- Adicionamos nosso primeiro servidor Win2012 AD em nossa estrutura Win2003 AD
- Lembro que houve alguns casos de problemas de segurança relacionados ao IE10/SSL/TLS que exigiriam intervenção manual (regedit e outras coisas), mas ainda estou tentando lembrar o que poderia ter sido
- Toneladas de atualizações do Windows
- Coisas como certificados invalidados vieram à minha mente, mas não encontrei nada disso
Pergunta 2. Alguma dessas coisas pode causar esse problema?
Atualmente, abandonamos completamente o farm de servidores, ou seja, temos apenas "balanceamento de carga do pobre homem" via DNS round robin (e sentimos especialmente falta do recurso de reconectar à sessão anterior, é claro)
Questão principal. Como posso colocar minha fazenda em condição de trabalho novamente?
EDIT: Eu deveria ter mencionado que alguns clientes tiveram sorte e não tiveram problemas com o farm RDP: aqueles que ainda estavam executando o Windows XP e seu cliente RDP mais antigo ...
EDITAR após o comentário: Parece que as principais atualizações culpadas KB3002657, KB3035017 não foram instaladas ou foram instaladas dias antes do início do problema nos servidores relevantes (clientes, servidores RDP, corretor, DCs), mas tentarei desinstalar eles de qualquer maneira...
ATUALIZAÇÃO Mais algumas informações:
- Melhorei o registro de eventos no corretor. De acordo com esse log, está tudo bem (sem aviso) e o redirecionamento da sessão é concluído normalmente. Acontece que, após um tempo limite, a sessão de destino é removida. Tentei (falhei) em conexões rápidas e nesse caso, a corretora até registrou que tentou reaproveitar uma sessão existente.
- Se o servidor RDP de destino estiver definido como "RDP-Sercurity" em vez de "negotiate", o redirecionamento funcionará (exceto que as mensagens de erro irritantes esperadas ocorrem no cliente)
- Eu tentei um farm completamente novo (ou seja, um corretor diferente com hosts diferentes) e o problema também pode ser reproduzido neste sistema. Isso pode sugerir que o problema está no lado do cliente.
ATUALIZAÇÃO com informações conforme solicitado por comentários
Se eu definir a segurança como "TLS 1.0" (em vez de "negociar") nos hosts RDP, o problema persistirá. Se eu definir como "RDP", o farm funcionará - mas todos terão que digitar sua senha duas vezes. Na situação de erro, por algum motivo, agora recebo simplesmente "Nenhuma conexão pôde ser estabelecida com as credenciais fornecidas" em vez do erro original. Isso é acompanhado por um evento de falha de login 4625 com status 0xc000006d, substatus 0. Antes que você pergunte: Todos os controladores de domínio têm seus relógios em boa sincronização; nenhuma configuração de compatibilidade LanMan foi definida no registro.
Os certificados nas configurações do cliente host RDP que funcionaram foram emitidos pela CA interna ainda confiável (confiável por todos de acordo com o GPO) e válidos até pelo menos quatro meses no futuro. Para testar, alterei-os para certificados "automáticos" e voltei, sem sucesso.
O texto original da mensagem de erro em alemão diz
Von Remotedesktopverbindung cann keine Verbindung mit dem Remotecomputer hergestellt werden.
Vom Remotecomputer "FARMNAME", mit dem Sie eine Verbindung herstellen möchten, werden Sie zum Remotecomputer "FARMMEMBER.DOMAIN" umgeleitet. Es kann nicht überprüft werden, ob diebeiden Remotecomputer zur gleichen Remotedesktop-Sitzungshostserverfarm gehören. Você pode usar o Farmnamen, ou o nome do computador, verificar se você deseja conectar um servidor remoto à área de trabalho remota.
Quando você for um administrador de rede, um administrador de rede, quando você tiver uma verificação RDP, o administrador será informado.
Wenn Sie eine Verbindung mit einem bestimmten Herstellen möchten, um es zu verwalten, geben Sie "mstsc.exe /admin" an der Eingabeaufforderung ein.
Para descobrir se alguma atualização recente do lado do cliente está com defeito, comecei com uma nova caixa do Windows 7 e testei após cada grupo de atualizações. Parece que a introdução do primeiro cliente melhor que o XP já causa problemas agora - mas as primeiras versões desse cliente fornecem uma mensagem de erro diferente (não que isso faça sentido):
Die Verbindung kann nicht hergestellt werden, da es sich bei dem erreichten Remotecomputer nicht um den angegebenen Computer handelt. Dies kann durch einen veralteten Eintrag im DNS-Cache verursacht werden. Verwenden Sie statt des Namens die IP-Adresse es Computers.
Parece bastante difícil encontrar a agulha no palheiro aqui, mas acredito que seja um erro de configuração em algum lugar. Seguir isso deve fornecer uma configuração de linha de base de trabalho:
<domain>para<farmname.domain>apontar para cada um de seus hosts de sessão no farm<sessionhost.domain>um com um nome alternativo de entidade<farmname.domain>e instalá-los / ativá-los para serviços RD em cada um de seus hosts de sessão<farmname>em<connectionbroker.domain>(todas as configurações em Modelos Administrativos/Componentes do Windows/Serviços de Área de Trabalho Remota/Host de Sessão de Área de Trabalho Remota/Agente de Conexão RD ):Distributed COM Users (built-in)<farmname.domain>Boa sorte!
Obrigado por todas as sugestões, mas nenhuma delas correspondeu. Não tenho ideia de por que ocorreu o padrão de mau funcionamento observado e descrito (e o desenvolvimento temporal do mau funcionamento), mas o culpado está oculto no que descrevi como
É KB3002567. Uma atualização que logo após seu lançamento ficou conhecida como "breaking RDP" - ou na verdade quebrando tudo. Ironicamente, uma rápida pesquisa após o primeiro encontro de nossos problemas já havia revelado isso (pelo menos os problemas de RDP, pois foi o que pesquisamos no Google), então marcamos KB3002567 (e alguns outros suspeitos) para desinstalar em nosso WSUS ( cf. minha observação otimista para esse fim no OP) e sincronização de atualização congelada por enquanto. O que não notamos foi que a versão do Windows Server 2003 desta atualização se considera não desinstalável. Assim, enquanto notamos durante uma atualização de teste como o patch foi removido com sucesso, por exemplo, de um servidor Win2008, pensamos que a remoção ocorreu com sucesso também em nossos servidores AD (Win 2003) durante a noite (já que eles imploravam por nada, atualização-sábia , no próximo dia). Como o problema persistia,totalmente quebrado - conseguimos contornar o problema em detrimento do conforto do usuário). A versão Win 2012, por outro lado , foiautomaticamente desinstalável. Como consequência, dependia de qual servidor foi usado para autenticação se o RDP funcionou ou não. Concluímos erroneamente que a reinicialização do servidor fez com que o problema "instalado" anteriormente aparecesse - quando, na verdade, a reinicialização aconteceu apenas para alternar as prioridades do servidor de autenticação. Também concluímos erroneamente que nossos testes de migração do AD eram a causa dos problemas e rebaixamos e removemos o servidor de 2012, começando a procurar por quaisquer problemas que esse jogo com o AD pudesse ter. Como o problema tinha aumentado constantemente de intensidade, não ficamos muito desconfiados quando notamos que a falha frequentemente se transformava em falha sempre no mesmo dia em que nos livramos do servidor AD 2012 (embora a conexão seja óbvia em retrospectiva).
Quando nossa pesquisa continuou apresentando as mesmas sugestões inúteis (verifique se a diferença de tempo entre os servidores é inferior a 5 minutos - verifique, são apenas frações de segundos; verifique se todas as associações de grupos relevantes estão definidas - isso realmente fica chato ao fazer isso um segundo tempo; verifique as entradas do DNS - há muito pouco no DNS que poderia ter passado despercebido; verifique se o KB3002567 não está instalado - ei, nosso WSUS cuidou disso, não é?) começamos a arrancar nossos cabelos. Quando então apareceu outra dica para o KB3002567, finalmente examinamos a lista de atualizações instaladas em nosso servidor Win2003 AD (caramba, isso realmente se tornou mais simples com os sistemas operacionais modernos) para surpreendentemente ainda encontrá-lo instalado. Desinstale manualmente, reinicie, todos felizes imediatamente!