MSRDP brokering via iRule

Hi all,

My company is beginning to jump on the virtual desktop bandwagon, and I am attempting to leverage my LTMs to reduce cost, and preclude the complexity that can come with adding a desktop brokering system to the mix.

Basically I have an RDP pool consisting of about 20 XP hosts. Load-balancing them using the msrdp persistence profile works fine, but there are a couple of caveats. I am attempting to use an iRule to analyze persistence records in order to determine where a new connection should be sent. I want to be able to take into account the scenario where a user may become disconnected for whatever reason, yet have the LTM refrain from routing a new connection to that system until any persistence records referencing it have expired. Simply limiting the number of connections is not sufficient for my purposes since the RDP connection would/could be reaped by the LTM prior to the session being terminated by the XP host. In effect I need to reserve the host for a predetermined amount of time regardless of the number of active connections.

Logically, the desired iRule would function as follows:

when LB_SELECTED {
if  { [ persist lookup msrdp * ]  contains [ LB::server addr ] }  {
  LB::reselect
  }
 }

Of course there are a number of issues with this, since the 'persist lookup' command does not seem to support the 'msrdp' mode or wildcards, but you get the idea. I have also implemented a variation of the universal persistence method suggested here: Click here but I still have the same problem in that I don't know or care what the persistence key is, just whether or not a persistence record exists for the currently selected pool member.

Long story short, I need to know if there is a way to dump the persistence table within an iRule, or otherwise return any records related to a known node address where the key is unknown.

Anyway, I've scoured the forums for information that could help me with this, but haven't come across anything yet. Thanks in advance for any advice the community may have to offer.

- Nathan