none
RDP Windows Server 2008 R2 RRS feed

  • Pergunta

  • Bom dia!

    Estou com o problema ao tentar fazer um acesso remoto em um Windows Server 2008, conforme o arquivo abaixo.

    Esta máquina está no domínio, e não tenho problemas de hora (ela roda w32tm na rede). Nos logs não apresenta nenhuma informação pertinente. Sabem me informar o que está ocorrendo?

    "Este computador  não pode se conectar ao computador remoto.

    Os dois computadores não estabelecem conexão no tempo determinado. Tente conectar-se novamente. Se o problema persistir, entre em contato com o administrador de rede ou suporte técnico."


    • Editado Miguel Longo terça-feira, 6 de maio de 2014 13:32
    terça-feira, 6 de maio de 2014 13:28

Respostas

  • Miguel,

    Enriqueceu com maiores informações e realmente ajuda para o Troubleshooting, isso está me "parecendo" problemas de tráfego, ou seja, quando há uma demanda muito alta de pacotes (input) de clients, o data stream ele se torna inacessível/corrompido causando disconnect ou não aceitando novas sessões. (Lembre-se que é apenas uma teoria e não de fato o que ocorre no seu ambiente).

    Para isso recomendo algumas ações:

    1) Atualização de Drivers (NICs) caso haja.

    2) Remover antivírus

    3) Verifique no registro do servidor que está sendo acessado via TS, se os valores abaixo correspondem:

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server] "KeepAliveInterval"=dword:00000001 "KeepAliveEnable"=dword:00000001

    Caso não, altere.

    4) Configure no servidor a seguinte GPO:

    Computer configuration -> Administrative templates -> Windows Component -> Terminal services -> Terminal server-> Session limits  Set Time Limit For Active Idle Terminal Services Session to Never

    5) Desabilite os recursos Offload da placa de rede (via prompt):

    • netsh int tcp set global chimney=disabled • netsh int tcp set global rss=disabled • netsh int ip set global taskoffload=disabled • netsh int tcp set global autotuninglevel=disabled • netsh int tcp set global congestionprovider=none • netsh int tcp set global ecncapability=disabled • netsh int tcp set global timestamps=disabled

    6) Desabilite IPv6 caso não use no ambiente.

    http://support.microsoft.com/default.aspx?scid=kb;EN-US;929852

    São ações recomendadas para o cenário, baseando-se pelos erros de terminal.

    Faça o teste, monitore e reporte quando tiver algum resultado



    Carlos Eduardo Gnochi de Oliveira


    terça-feira, 6 de maio de 2014 16:53

Todas as Respostas

  • Verifique se a máquina:

    - está pingando

    - se o firewall está habilitado

    - se o antivirus não pode estar bloqueando


    Bruno Vasconcellos Batalha MCP/MCT/MCTS/MCITP-SA 2008/VCP 4.1

    terça-feira, 6 de maio de 2014 13:47
  • Além das sugestões do colega acima. Verifica se o problema ocorre tanto por nome quanto por IP (validar questões de DNS)

    Verifique se o serviço de TS está ativo.

    A chance de ser FW é bem considerável.


    Carlos Eduardo Gnochi de Oliveira

    terça-feira, 6 de maio de 2014 13:50
  • Nenhum problema de conectividade! Isso ocorre de forma esporádica. Eu consigo conectar, porém chega uma hora que ocorre isso.
    terça-feira, 6 de maio de 2014 14:06
  • Bom dia!

    Nenhum problema de firewall. Estamos no mesmo seguimento de rede e o firewall da máquina está desabilitado.

    Isso ocorre de forma esporádica. Eu consigo conectar, porém chega uma hora que ocorre isso.

    Abraço!

    terça-feira, 6 de maio de 2014 14:07
  • Então ai temos outro cenário. Qual a frequência? Se é de forma esporádica, exemplifique em quanto tempo (média)

    2x na semana?

    Como está as questões de infra/rede? Drivers? É virtual?

    Verifique primeiro por atualizações no ambiente, o que tiver "outdated", procure atualizar.


    Carlos Eduardo Gnochi de Oliveira

    terça-feira, 6 de maio de 2014 14:09
  • Bom dia Carlos!

    Vou tentar ser o mais informativo possível. Vamos lá!

    - Esta máquina está sendo virtualizada num Xen (Citriz), possui todos os drivers instalados (para-virtualizado);

    - Está num Data Center e acesso a mesma via tunel IPSec;

    - O problema ocorre em medias 1 vez a cada dois dias e máquina que fazem o acesso remoto através do TMG  e ocorre somente nesta máquina.

    Dei uma analisada nos logs do Windows e encontrei algumas informações que podem ser relevante. Estou recebendo o evento 50 e 56 do TermDD. Segue:

    1:

    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
    <System>
    <Provider Name="TermDD" /> 
    <EventID Qualifiers="49162">50</EventID> 
    <Level>2</Level> 
    <Task>0</Task> 
    <Keywords>0x80000000000000</Keywords> 
    <TimeCreated SystemTime="2014-05-05T12:55:22.920736200Z" /> 
    <EventRecordID>16234</EventRecordID> 
    <Channel>System</Channel> 
    <Computer>###</Computer> 
    <Security /> 
    </System>
    <EventData>
    <Data>\Device\Termdd</Data> 
    <Data>X.224</Data> 
    <Binary>0000240002004C000000000032000AC00000000032000AC000000000000000000000000000000000270000000300002002F08064000703EB701212001700F003EA0301000001040024000000</Binary> 
    </EventData>
    </Event>

    2:

    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
    <System>
    <Provider Name="TermDD" /> 
    <EventID Qualifiers="49162">56</EventID> 
    <Level>2</Level> 
    <Task>0</Task> 
    <Keywords>0x80000000000000</Keywords> 
    <TimeCreated SystemTime="2014-05-05T12:55:22.920736200Z" /> 
    <EventRecordID>16235</EventRecordID> 
    <Channel>System</Channel> 
    <Computer>###</Computer> 
    <Security /> 
    </System>
    <EventData>
    <Data>\Device\Termdd</Data> 
    <Data>192.168.6.2</Data> 
    <Binary>0000040002002C000000000038000AC00000000038000AC00000000000000000000000000000000032000AD0</Binary> 
    </EventData>
    </Event>

    Vi que é possível encontrar o erro com os ultimos 4 bytes do numero binário, porém não encontrei nada a respeito.

    Um abraço!


    • Editado Miguel Longo terça-feira, 6 de maio de 2014 16:21
    terça-feira, 6 de maio de 2014 16:18
  • Miguel,

    Enriqueceu com maiores informações e realmente ajuda para o Troubleshooting, isso está me "parecendo" problemas de tráfego, ou seja, quando há uma demanda muito alta de pacotes (input) de clients, o data stream ele se torna inacessível/corrompido causando disconnect ou não aceitando novas sessões. (Lembre-se que é apenas uma teoria e não de fato o que ocorre no seu ambiente).

    Para isso recomendo algumas ações:

    1) Atualização de Drivers (NICs) caso haja.

    2) Remover antivírus

    3) Verifique no registro do servidor que está sendo acessado via TS, se os valores abaixo correspondem:

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server] "KeepAliveInterval"=dword:00000001 "KeepAliveEnable"=dword:00000001

    Caso não, altere.

    4) Configure no servidor a seguinte GPO:

    Computer configuration -> Administrative templates -> Windows Component -> Terminal services -> Terminal server-> Session limits  Set Time Limit For Active Idle Terminal Services Session to Never

    5) Desabilite os recursos Offload da placa de rede (via prompt):

    • netsh int tcp set global chimney=disabled • netsh int tcp set global rss=disabled • netsh int ip set global taskoffload=disabled • netsh int tcp set global autotuninglevel=disabled • netsh int tcp set global congestionprovider=none • netsh int tcp set global ecncapability=disabled • netsh int tcp set global timestamps=disabled

    6) Desabilite IPv6 caso não use no ambiente.

    http://support.microsoft.com/default.aspx?scid=kb;EN-US;929852

    São ações recomendadas para o cenário, baseando-se pelos erros de terminal.

    Faça o teste, monitore e reporte quando tiver algum resultado



    Carlos Eduardo Gnochi de Oliveira


    terça-feira, 6 de maio de 2014 16:53
  • Boa tarde Carlos!

    Muito obrigado pela resposta! Vou fazer estas alterações e posto os resultados. Irei monitorar 3 dias.

    Um abraço!

    terça-feira, 6 de maio de 2014 17:35
  • Carlos, problema corrigido!

    Muito obrigado!

    Abraço!

    quarta-feira, 7 de maio de 2014 20:19