[WS2k8 R2] RDP'en onresponsive

[Verwijderd]

Ik kamp al een tijd met een vervelend RDP probleem dat maar niet opgelost geraakt.

De situatie:
* 1 RDP license server (User CALS) met WS2k12 R2. Server is geen DC en is member van Terminal server License server group.
* 2 RDP server die mekaar load balancen (50/50) en een productie applicatie hosten. (WS2k8 R2)

Het probleem:
* Op onregelmatige tijdstippen is het niet meer mogelijk een RDP connectie op te zetten naar RDP server. Wanneer ik dit toch probeer, wordt mijn RDP sessie direct automatisch afgelogd nadat ik mij authenticeer. De enige manier om nog op deze server te connecteren is via Hyper-V manager. Nadat ik deze server dan herstart, werkt alles terug. Het vreemde is dat ik hier geen patroon in terugvind. De situatie kan bvb een hele week werken en dan de week daarop plots probleem vertonen.

Deze voormiddag deed zich RDP issue terug voor. Op deze moment waren er een tiental RDP sessies actief. Ik heb deze gebruikers gecontacteerd en gevraagd of ze konden afloggen en terug aanloggen zodat ze automatisch op de andere, werkende server terechtkwamen. Nadat zich een vijftal users hadden afgelogd, kon ik plots terug RDP'en op de "slechte" server. Buiten de users die afgelogd waren, is er niets veranderd. (ik had geen services ed herstart)


Troubleshooting:
* Ik ben begonnen met de eventlog na te kijken van zowel license server als RDP servers.
Op de RDP server vind ik mijn mislukte RDP sessies niet terug. Via Microsoft-Windows-TerminalServices-LocalSessionManager/Operational. Ook in application & eventlog vind ik hier niets over terug.

Op de license server, staat de system log vol events à la:
The Remote Desktop license server cannot update the license attributes for user "X" in the Active Directory Domain "Y". Ensure that the computer account for the license server is a member of Terminal Server License Servers group in Active Directory domain "domo.group".
=> Dit is dus wel degelijk het geval. Dit event komt ook meerdere malen/dag voor dus het zou mij verwonderen dat dit oorzaak is van het probleem.

Windows Firewall staat uit op beide RDP server dus kan ook niet oorzaak zijn. Google-speurwerk levert mij ook geen info op waardoor ik hier probeer een antwoord te vinden.
Beide RDP server zijn hyper-v VM's die draaien op een fysieke IBM-server die "maar" een linkspeed heeft van 100Mbps. (denk niet dat het ermee te maken heeft maar geef het toch mee)

[Question Mark]

Hoe is je loadbalancing precies ingeregeld?

[Verwijderd]

Question Mark schreef op dinsdag 05 mei 2015 @ 16:10:
Hoe is je loadbalancing precies ingeregeld?

De 2 RDP servers zijn in sé Citrix workers die door load balancing policies geregeld worden. (Xenapp 7.5 farm)

[Question Mark]

Ah.... Citrix werkt iets anders qua loadbalancing dan MS RDP. Ik neem ook aan dat je dan ICA sessies opzet, en geen RDP sessies zoals je in je topicstart noemt?

Controleer de load index van je load evaluator policies even als het probleem optreedt. (qfarm /load). Als de load van de server die problemen geeft een normale waarde aangeeft heb je in elk geval issue's met loadbalancing uitgesloten.

Hoe verbinden je clients overigens? Je meldt dat je een RDP sessie opzet naar een server, maar het hele idee van Citrix loadbalancing is dat je een sessie opzet naar je published app/desktop. De farm regelt dan wel dat je op de minst drukke server uitkomt (afhankelijk van je load balancing policy's).

Als jij handmatig probeert te verbinden met een Xenapp server die op dat moment een "high load" rapporteert kan ik me voorstellen dat je niet mag verbinden...

[ Voor 10% gewijzigd door Question Mark op 06-05-2015 14:59 ]

[Verwijderd]

Question Mark schreef op woensdag 06 mei 2015 @ 14:53:
Ah.... Citrix werkt iets anders qua loadbalancing dan MS RDP. Ik neem ook aan dat je dan ICA sessies opzet, en geen RDP sessies zoals je in je topicstart noemt?

Controleer de load index van je load evaluator policies even als het probleem optreedt. (qfarm /load). Als de load van de server die problemen geeft een normale waarde aangeeft heb je in elk geval issue's met loadbalancing uitgesloten.

Hoe verbinden je clients overigens? Je meldt dat je een RDP sessie opzet naar een server, maar het hele idee van Citrix loadbalancing is dat je een sessie opzet naar je published app/desktop. De farm regelt dan wel dat je op de minst drukke server uitkomt (afhankelijk van je load balancing policy's).

Als jij handmatig probeert te verbinden met een Xenapp server die op dat moment een "high load" rapporteert kan ik me voorstellen dat je niet mag verbinden...

Wel, deze servers worden door handscanners benaderd die de applicatie hierop rechtstreeks via RDP opstarten.
Deze servers bieden de applicatie ook via Citrix aan voor Windows clients.
Indien het vermelde issue zich voordoet, probeer ik eerst en vooral met mijn latop te RDP'en in de server en merk dat dit niet lukt.

Ik vermoed dat het geen Citrix issue is maar RDP. (daarom dat ik Citrix ook niet vermelde in mijn startpost)
De loadbalancing door Citrix werkt perfect. (users zijn altijd 50/50 verdeeld over beide servers)
Deze servers zijn krachtig genoeg om afzonderlijk de hele organisatie te ondersteunen.

[Question Mark]

Verwijderd schreef op woensdag 06 mei 2015 @ 15:10:
[...]
Deze servers zijn krachtig genoeg om afzonderlijk de hele organisatie te ondersteunen.

Houdt er wel rekening mee dat de default loadbalancing rule(s) rekenening houden met het aanloggen van users. Dat is dermate zwaar proces voor een server dat tijdens het aanloggen van een user de load standaard op "high" gezet wordt, en er tijdelijk dus geen nieuwe sessie naar geredirect worden. (load throttling).

Ongeacht hoe zwaar je server dan ook is, op dat moment wordt hij door de IMA service uit de loadbalancing gehaald. Misschien niet helemaal gerelateerd aan je probleem, maar wel even het vermelden waard.

Lastige problemen dit, zeker aangezien de eventvwr ook geen aanknopingspunt vind. Ik zou dan toch op het moment van problemen toch even met het commando Qfarm snel even wat testjes gaan doen.

Zie ook: http://support.citrix.com/article/CTX112082