Load balancing terminal servers w/o Session Directory

Just to clarify semantics, you said you were "load balancing 2 terminal servers", but I assume from the rest of the post you are actually LB across two RDP think clients, using 2X RDP thin clients. In either case, the issues below apply, but if you really have Windows Terminal *Servers*, then enabling Session Directory is the easiest solution to your problem.

 

 

Unfortunately, there are limitations to what you can do without Session Directory enabled. The session directory token allows a different session to check with the Session Directory server to see if there is a current connection with an RDP client pending with a server. Without that token, BIG-IP cannot maintain that persistence. Instead it uses a hash method that work as long as the user logs off properly after a session. If not, there is a x:1 chance (where "x" is is the number of RDP clients), that the thin client will connect to the correct thick client. To make matters worse, session directory is not an option with RDP clients like it is with WTS.

 

 

You may want to investigate solutions from HP known as Consolidated Client Infrastructure. HP may have some substitutions for the Session Directory server in an RDP/thin-thick client environment. Another alternative, although not available as far as I know, is to create your own "token exchange" using an iRule.

Does thi issue happens without the 2X clients. I'm wondering if this is something linked to that client.

 

 

Also if you are looking for how to set-up session directoy you may want to check out the guide on Session Directory and Load Balancing from Microsoft at:

 

 

http://download.microsoft.com/download/8/6/2/8624174c-8587-4a37-8722-00139613a5bc/SessionDirectory.doc

 

 

- James

 

 

- James

No, the same behavior will be observed with Microsoft RDP clients. If session directory is not enabled or not supported, the client has nothing to verify that a current session exists before establishing a *new session* - even when using the the BIG-IP WTS persistence setting. New connections within the same session ARE persisted to the same device (WTS or RDP client) when WTS persistence is used.

We do have two terminal services servers. We are using thin clients that rdp into these servers. Both are Win2k3 Enterprise so Session Directory is an option. However from what I've read this should still be working without Session Directory enabled. From my understanding that is why that option is in the msrdp persistence profile.

 

 

I ran across the timeout option in the msrdp persistence profile. Could that be causing this. It is simple but you never know. It was set to 300 seconds. We have our server set to 3 hours for disconnected sessions. Would it be correct to set that timeout to 3 hours?

Changing the timeout option may help a little bit, but the basic issue is still not solved. With Session Directory disabled, msrdp persistence will persist to the same server during the same session. Once you disconnect (but *don't log out*), the next time you log in, you are a new user. There is no token to connect you with a session that is running on a particular terminal server. Your experience proves validates this behavior. If you enable Session Persistence it will work. So if you want it to reconnect to an already establish connection, you have to enable Session Persistence, or find a way to replicate the functionality of session directory. It's not that the session times out too early, it's that you have no way of knowing the existence of an existing session. Increasing the timeout will actually aggrevate the problem more. In fact, if the timeout is too long, ALL available servers could theoretically be "tied up" and no user could connect to either terminal servers. If anything, lower the timeout.

When enabling session directory on the Terminal Server, it will send the cookie, and the string that the F5 is looking for is msts=. When session directory is NOT enabled on the Terminal Server, and the F5 msrdp profile checkbox is disabled, it is looking for the string mstshash=. Here is an exerpt from my sniffer capture when utilizing the rdp profile with session directory disabled on the server and the BigIP:

 

 

 

0x0030 0000 0043 6f6f 6b69 653a 206d 7374 7368 ...Cookie:.mstsh

 

0x0040 6173 683d 6534 3838 6263 4065 720d 0a ash=testusr@te..

 

 

 

 

And here is the persistence entry in my F5:

 

 

 

PERSISTENT CONNECTIONS --

 

Mode: msrdp Value: testusr@te

 

Virtual: 10.1.1.10:3389 Node: 10.10.10.10:3389 Age: 260sec

 

 

 

 

The key to using the msrdp persistence without session directory is that the user credentials need to be supplied UP FRONT with the client request. If they are supplied AFTER the Terminal Server has painted a page for you, persistence will not work. This is because once the session has begun, the F5 no longer has visibility into the stream since there isn't a published decode for the rdp protocol. The first data packet after the TCP handshake, however, is where the cookie is supplied (either the routing token or the username) A couple notes from my experience:

 

 

1) If no credentials are supplied, the cookie isn't sent. Therefore, msrdp persistence without session directory is useless

 

 

2) If using the RDP client on a desktop, your credentials from your local PC login are sent by default. This is OK if the terminal server you are logging into is in the same domain as your PC, but it's something to be aware of.

 

 

3) Our thin clients are all built with a default credential (I'm not sure why or if that's configurable, I don't work on that side of the house) so if we used msrdp persistence without session directory we'd not achieve loadbalancing. We use session directory for thin clients because of this.

 

 

HTH....Jason

The timeout is all that it was! I changed that and the BIGIP is keeping track of sessions and redirecting them correctly! Since our TCs send the credentials at the time of connection it is working great without Session Directory.

 

 

Thanks for your help guys!

Great! But does that mean you increased or decreased the timeout? I would think you increased it so it would "remember" your session longer. Will the timeout be long enough or will you have users that want to reconnect to a session the next morning? Just out of curiosity, why not use Session Directory? Was the session directory a device you didn't want to manage? was it a cost issue?

 

 

Probably the last thing you want to do is answer a bunch of questions after you issue if resolved ;-), I'm just trying to determine if my perception of how often Session Dir is used compared to not is accurate.

It is only in niche areas where we choose not to use session directory.

Citizen, or anyone else...

 

 

I'm trying to test RDP persistence with the default RDP persistence profile and an iRule you were working on before (Click here and later Click here).

 

 

I believe the customer is unable to use session directories as they don't have enterprise Windows servers. I've been testing from WinXP and Win2003 standard clients to WinXP and Win2003 standard terminal services. I have tried testing using 'mstsc /v:VIP' and entering the username and password in mstsc before making the request.

 

 

I never see the mstshash in the client connection. The only intelligible string in the requests is the hostname of the client.

 

 

Is this expected? Is there anything I can do other than use session directories on the TS servers to entice the client to send something I can persist on like the mstshash that's described above?

 

 

Thanks,

 

Aaron