Issue with providing load balancing information using AxMSTSCLib

I am trying to establish a remote desktop connection via a remote desktop session broker in my C# application using the 'AxInterop.MSTSCLib' where I encounter problems with the transfer of the load balancing information.

Basically, I create a new object and set the basic parameters. A connection directly to a single Remote Desktop (RD) server is already possible with this:

var rd = new AxMsRdpClient11NotSafeForScripting();

rd.Server = "target-server.domain.local";
rd.UserName = "user";
var secured = (MSTSCLib.IMsTscNonScriptable)rd.GetOcx();
secured.ClearTextPassword = "password";

The RD environment I want to connect to consists of multiple RD services collections, each managing one or more RD Servers. For new RD connections, RD clients connect to an RD broker server, which redirects the clients according to the individual load balancing information they provide.

To provide this load balancing info, using mstsc.exe and an .rdp file I provide the setting 'loadbalanceinfo:s:tsv://MS Terminal Services Plugin.1.99999' where '99999' is the name of the targeted RD Collection which works fine. To implement this in MSTSCLib, I have to set it with 'rd.AdvancedSettings9.LoadBalanceInfo'.

However, as this post on the Microsoft Technet forum also describes, the load balancing info string must first be re-encoded.

var lbinfo = "loadbalanceinfo:s:tsv://MS Terminal Services Plugin.1.99999";

if (lbinfo.Length % 2 == 1) lbinfo += " ";
lbinfo += "\r\n";
var b = Encoding.UTF8.GetBytes(lbinfo);
var final = Encoding.Unicode.GetString(b);

rd.AdvancedSettings9.LoadBalanceInfo = final;

According to the last comment in the Technet post, the number of bytes must be even, so a space (U+0020) is added if nessesary.

With 'rd.Connect()' the connection is established and my client reaches the connection broker. In the first step my connection request appears in the logs of the broker server:

[TerminalServices-SessionBroker (Operational)]
The Remote Desktop Connection Broker has received a connection request for user {user}.
Notes in the RDP file (TSV URL) = 'tsv://MS Terminal Services Plugin.1.99999 ' //two empty spaces after the 99999 Original application = NULL
The call comes from the redirection server = broker.domain.local
The redirector is configured as a virtual machine redirector.

Note the two spaces at the end of the TSV URL that gets added by the used code because the bytes count would be uneven otherwise. The only difference to mstsc.exe is that there is only one space (which is the new line break we also add I guess) displayed.

In the next step the error occurs and our connection attempt fails. It says 'The farm specified for the connection does not exist.' The OnDisconnected event is triggered and provides me the information: 'DiscReason: 3' and 'ExtendedDisconnectReason: 1040'.

My guess: Because of the space we add, the name of the RD collection can't be assigned correctly anymore. If we compare the passed information (loadbalanceinfo:s:tsv://MS Terminal Services Plugin.1.99999) on byte level, we also see that this added space is the only difference:

mstsc.exe 

74 73 76 3a 2f 2f 4d 53 20 54 65 72 6d 69 6e 61 6c 20 53 65 72 76 69 63 65 73 20 50 6c 75 67 69 6e 2e 31 2e 39 39 39 39 39 0d 0a

AxMSTSCLib: 

74 73 76 3a 2f 2f 4d 53 20 54 65 72 6d 69 6e 61 6c 20 53 65 72 76 69 63 65 73 20 50 6c 75 67 69 6e 2e 31 2e 39 39 39 39 39 20 0d 0a //Note the third last byte, the U+0020, which we added to achieve an even byte count.

If I do not add the space and the number of bytes (43) is thus not even, I see in WireShark that the TPKT packet is not even sent anymore. The broker server, according to its logs, also takes no notice of the connection attempt. The OnDisconnected event provides me the information:: 'DiscReason: 4' and 'ExtendedDisconnectReason: exDiscReasonNoInfo'. So it seems that the AxMSTSCLib already assumes that the byte number is even.

Unfortunately, I can't figure out how mstsc.exe manages to successfully transmit the same odd string. On byte level I work supposedly identically.

I have uploaded the entire byte contents of the TPKT packages here for better comparison: https://pastebin.com/tLtfWHiP

I am grateful for any ideas.

Thanks and regards

Lukas P.