Hi Neeraj,
the persistence table dump above actually only shows
two persistence records for the persistence values of "AVPR-PMPS" and "PSMConnec".
The seven lines just display the retrieved entries from the different TMM instances (traffic management microkernel; it looks like you are running a system with 4 virtual cores tmm0 - tmm3).
The msrdp persistence profile looks for the client logon name (used to be stored in the MSTSHASH-cookie - if I remember right; you can track it in a tcpdump) and keeps it along with the mapping to one of the real servers selected initially in the persistence table.
Unfortunately the persistence value seems to be limited to eight characters only in your TMOS version and with a domain information as prefix to a logon name you may end up with a very small number of persistence table entries, as the trailing data (beyond the eight characters) is simply ignored for the load balancing / persistence decision .
As a result nearly each new incoming request seems to match an existing persistence records and will be forwarded to the related pool member.
This issue is not new and I would like you to raise a support case and a feature request, please.
Recently I tried to use "least connections" load balancing method with a customer. Unfortunately it seems the connection brokering forced the client to open a direct connection to the selected RDP server and the BIG-IP was bypassed. That´s why no current connections showed up in the pool member statistics and "least connections" selected always the first available pool member of the configuration as all members had the "same" number of connections (0) from the BIG-IP perspective.
Perhaps it was necessary to adjust settings on the terminal server client or the RDP server to get all connections "routed" through the BIG-IP but I had no chance to evaluate it by now. To achieve at least a distribution among the available RDP serves I configured "round robin".
Thanks, Stephan