XenApp : Sessions are not getting load balanced between XenApp servers in a Delivery Group due to pending sessions

XenApp : Sessions are not getting load balanced between XenApp servers in a Delivery Group due to pending sessions

book

Article ID: CTX239314

calendar_today

Updated On:

Description

Sessions are not getting load balanced between XenApp servers in a Delivery Group although load is comparatively less on some server.
In Citrix Studio you might notice there are sessions without any user name and those session shows as 'Connected' as Session State.
User-added image
 

Resolution

  1. Avoid accessing same server through HDX and RDP both. Use only one method or enable Multiple RDP Sessions.
  2. Restart ‘Citrix Desktop Service’ service on the affected server. It will clean-up those pending sessions.
  3. Set a policy to increase "Concurrent Logons Tolerance" say 10 or higher and filter it to the delivery group. 

Problem Cause

There are more pending sessions on the XenApp server than configured "Concurrent Logons Tolerance"
Default "Concurrent Logons Tolerance" is 2. You can set to higher number through policy.

How to check if there is any pending sessions:
On one of the Citrix Delivery Controller launch PowerShell and execute following commands

asnp Citrix*
Get-BrokerMachine | Select DNSName, LoadIndex, LoadIndexes, SessionCount, SessionsPending | ft

User-added image


Reason for Pending Session:
  1. If an user open a console session to the server and then RDP to it. This issue is not seen in latest XenApp releases.
  2. If an user open an HDX session to the server and then RDP to it. HDX session get disconnected when user try to connect the server through RDP.  Stealing ICA to RDP session is not supported on Server VDA. You will receive following message on RDP session.
 User-added image
Advised to avoid this scenario. Else enable Multiple RDP Sessions on the server.

How to check user name of those pending sessions:
Click on one of the session with Current User as blank and Session State as ‘Connected’ you will see the Protocol used for the session is RDP.

On one of the Citrix Delivery Controller launch PowerShell and execute following commands

asnp Citrix*
Get-BrokerSession -ConnectionMode Unbrokered -SessionState Connected| Select UntrustedUserName, MachineName, Protocol

User-added image

On CDF Logs
There were several “dangle” RDP sessions, the reason why they became dangle is DDC got the connection validation request, but then never received related Logon and LogonComplete notification from VDA:
       
On DDC Traces:
DAL >>> NotifySessionConnect(S-1-5-21-241423987-4053356358-3184354630-4112, 94F203B6814C0041CA4CE84814BB1F08:636378877881245258, 37c67009-7a6b-4818-8838-6ea451e36835, Desktop, Unbrokered, S-1-5-21-241423987-4053356358-3184354630-1640, domainname\userid, RDP, 202.164.30.65, CCL-CHC-RDSH2)
TicketingService.Validate(Worker=S-1-5-21-241423987-4053356358-3184354630-4112, Session=37c67009-7a6b-4818-8838-6ea451e36835): Result: Allow
 
On VDA Traces:
StackManager.ValidateConnection3: ValidateResult ALLOW, Session Key 37c67009-7a6b-4818-8838-6ea451e36835, Brokered User SID , IsReconnect False, CredentialsType 
=========>>>>> StackManager.NotifySessionEvent(37c67009-7a6b-4818-8838-6ea451e36835): Enter(SessionEvent:SESSION_EVENT_DISCONNECT, SessionReasonCode:SESSION_EVENT_REASON_CONNECTION_FAILURE, rdsCalId:0)
>>BAD-BAD<< Dangling Session sessionKey = 37c67009-7a6b-4818-8838-6ea451e36835