Terminal Server 2008R2 connectie probleem

[metallicelmo]

Hi,
Op een aantal lokaties hebben wij virtuele Terminal Servers draaien. Het besturingssysteem van deze Terminal Servers is Windows Server 2008R2 met laatste Service Pack.
De onderliggende laag hiervan is VMware ESX / ESXi versie 4.0 / 4.1 op HP Proliant ML350 G6 servers

Nu het probleem:
Met grote regelmaat melden de gebruikers dat ze uit hun sessie worden gegooid. Onderstaande foutmelding krijgen ze dan te zien op hun scherm:



Als je op OK klikt en vervolgens weer opnieuw verbinding maakt kom je netjes weer terug in je nog openstaande sessie. Dit gebeurd helaas meerdere malen per dag.

-Er wordt een mix gebruikt van Thinclients, Windows XP / Windows 7 machines, 32 en 64 bit. allemaal zelfde foutmelding zo nu en dan.
-Verschillende modellen switches ( HP, 3Com )
-Op alle pc's is de laatste Remote Desktop Client versie 7 geinstalleerd.

In het logboek van de server komt het volgende naar boven op het tijdstip van de foutmelding:
EventID 56 - TermDD

The Terminal Server security layer detected an error in the protocol stream and has disconnected the client "IP van de client"

Wij hebben werkelijk van alles geprobeerd, andere switches, andere pc's, instellingen op de server aangepast voor remote desktop services maar het enige wat lijkt te werken is het downgraden van de Remote Desktop Clients op de pc's zelf. Terugzetten naar RDP client 5.2 in ons geval.

Ik kan er maar niet achter komen waar dit mee te maken kan hebben.. Heeft iemand eens zoiets gehad?

[nielsl]

mogelijk ben je deze al tegengekomen, maar hier wordt aangegeven hoe je van de foutcode die wordt gegeven iets bruikbaars kan maken, misschien kun je daar meer mee:

http://blogs.technet.com/...6-with-source-termdd.aspx

*edit*
en er wordt hier http://social.technet.mic...46-49f9-a13f-095b124328fd (weleenswaar op thuisbakken hardware) gesproken over problemen met de NIC drivers. mogelijk kun je nagaan of het op een bepaald type client gebeurt? Of dat er sprake is van meerdere type NICs?

*edit2*
er wordt op bovenstaande site ook gesproken over een klapperende (VPN) verbinding. Mogelijk klappert de connectie. Ligt er een tunnel van de locatie naar het VLAN met de terminal servers? Mogelijk kun je dan een continue ping naar een netwerkobject uitvoeren om te kijken of alles stabiel loopt?

[ Voor 56% gewijzigd door nielsl op 09-08-2011 21:25 ]

[metallicelmo]

nielsl schreef op dinsdag 09 augustus 2011 @ 21:22:
mogelijk ben je deze al tegengekomen, maar hier wordt aangegeven hoe je van de foutcode die wordt gegeven iets bruikbaars kan maken, misschien kun je daar meer mee:

http://blogs.technet.com/...6-with-source-termdd.aspx

*edit*
en er wordt hier http://social.technet.mic...46-49f9-a13f-095b124328fd (weleenswaar op thuisbakken hardware) gesproken over problemen met de NIC drivers. mogelijk kun je nagaan of het op een bepaald type client gebeurt? Of dat er sprake is van meerdere type NICs?

*edit2*
er wordt op bovenstaande site ook gesproken over een klapperende (VPN) verbinding. Mogelijk klappert de connectie. Ligt er een tunnel van de locatie naar het VLAN met de terminal servers? Mogelijk kun je dan een continue ping naar een netwerkobject uitvoeren om te kijken of alles stabiel loopt?

Netwerkdrivers heb ik niet gecheckt, vreemde is wel dat het op hetzelfde netwerk gebeurd met verschillende hardware (pc / thinclient), VPN is niet in gebruik en er zijn ook geen VLANs. Het is één netwerk waarin de server zit samen met de werkstations.

Ik ga die site eens checken, bedankt voor je reactie

[nielsl]

mogelijk gebruiken die verschillende PC' s wel hetzelfde intel / broadcom chipje? En kijk ook goed naar de NIC drivers van je server, dat is immers het punt waar alles samen komt.

[Question Mark]

metallicelmo schreef op dinsdag 09 augustus 2011 @ 10:24:
instellingen op de server aangepast voor remote desktop services

Wat heb je precies aangepast? Kijk even naar de rdp compressie setting op de server. Windows 2008R2 default nl. naar maximale compressie en dat wil nog wel eens problemen geven.

[Trommelrem]

vmxnet3 of E1000?

[degroot]

check je performances is van je vm machine!

[Pieter Kimpen]

We hebben hier hetzelfde probleem. Sinds we alle VMWare ESX machines hebben geupgrade naar ESX 4.1 treed het probleem veel minder op (lees 1 keer om de 2 soms 3 weken). Voor deze upgrade hadden we ESX 3.5

Zijn je VM's voorzien van de laatste VMWare tools en de laatste Virtual hardware (versie 7)?
De sites die staan opgegeven heb ik een half jaar geleden al doorgespit (als ook voor onze Windows 2008 x64 omgeving enkele patches geinstalleerd). Hieroor verminderde het probleem wel maar was het niet helemaal weg.

Pas nadat we alle hosts geupgrade hadden kwamen we tot een acceptabel en werkbaar niveau.
De patches waarover ik spreek zijn normaalgezien niet van toepassing op een windows 2008 R2 server.
Indien je dit gaag hebt kan ik je hiervan de links geven.

Ik volg dit topic even mee, misschien komt er toch nog een oplossing uit de bus.

@trommelrem: we maken inderdaad gebruik van de E1000 netwerkkaart in de VM's Of dit voor de TS ook zo is kan ik niet zeggen.

[Joseph]

Kleine vraag: Is RemoteFX ingeschakeld?

[ResuCigam]

Pieter Kimpen schreef op vrijdag 12 augustus 2011 @ 09:47:
We hebben hier hetzelfde probleem.
we maken inderdaad gebruik van de E1000 netwerkkaart in de VM's.

Waarom gebruiken jullie de E1000, volgens mij is dat een oude compatibilty mode. Ik gebruik hier vmxnet3 en heb zulke problemen nooit dus misschien is dat een poging waard.

[Question Mark]

Voordeel van vmxnet is verder dat deze wat minder cpu-cycles trekt. Punt van aandacht is wel dat Windows deze driver standaard niet kent, hij komt mee met de installatie van de vmware tools.

[Trommelrem]

De vmxnet3 driver kan met dism worden geintegreerd in de Windows DVD. Zelfs de PVSCSI driver kan worden geintegreerd waardoor je plotseling kunt booten van PVSCSI drives
(booten vanaf PVSCSI wordt officieel niet ondersteund, maar kan performance-wise voor een terminal server wel handig zijn)

[Pieter Kimpen]

Ok bedankt voor de tip! Ik probeer het vanavond even uit als de gebruikers naar huis zijn.
Sorry voor de topickaping...