Terminal Service Plus

Hello,
We had a requirement to run TSPlus (8.10.3.28) via IIS, so i've followed your process outlined in the documentation. The login page now loads successfully.
Upon logging in, it is meant to load a RDP session via HTML5, but now we get the following error occuring;

HTML5 Internet Access
Establish connection v3.71...
X sec. (websocket)

that runs for 30 seconds before the next error

HTML5 Internet Access
Establish connection v3.71...
X sec. (xhr-polling)

that runs for 30 seconds as well. It then goes back to the first error for another 30 seconds, then finally stops and displays;

ALERT!
Check your connection! You have reached the maximal timeout:31

We never had the issue prior to shifting to IIS. Are there any other settings, permissions, required after the move?

[*]I've made sure the CGI handler is enabled
[*]the cgi-bin folder is set as an application
[*]The HTTP port is set to 81 not 80 (though i'm testing via https:443)
[*] The following folders appear in IIS under the website; cgi-bin, downloads, prints, software, var
[*] The original TSPlus install is located in a different location though.

Thank you for you help.

We never had the issue prior to shifting to IIS.

html5 gateway consist of several modules.
1. Port unificator that runs on default ports 80 and 443 with SSL instance
2. RDP client.
3. HTML5 server
4. Built-in web-server that runs on port 81 as default

Now let's assume some browser requests some page on port 443 or 80, the port unificator notices it and forwards the request to port 81 where the built-in web server listens and servers the .html pages.
Afterwards the browser creates websockets connection on port 443 or 80, the port unificator notices it and forwards the request internally to the html5 server, it get's not sent to other instances, it gets processed internally.

The html5 server gives the user the choice to use IIS or Apache as third server, so that it get's used instead built-in web server (position 4.), but your IIS should listen on port 81 and not on already taken by html5 server ports 80/443, so that any http request processed on port 80/443 gets forwarded to port 81 where your IIS listens.

That what you did, you started your IIS on port 80/443, and IIS does not support Websockets connections. It will serve for you .html pages but when Websockets request arrives on port 80/443 than IIS does not know what do with this request, therefore the client side has firstly tried to create Websockets connection than after failure XHR connection, and than timed out.
In fact you removed the server side html5 server and that was the fault.

Always have in mind, the html5 server has to be first in chain and IIS the next one.
In this configuration the SSL role takes always the html5 server, so the certificate has to be converted to jks format and run with html5 rather than processed by IIS.

juwagn wrote:

We never had the issue prior to shifting to IIS.

html5 gateway consist of several modules.
1. Port unificator that runs on default ports 80 and 443 with SSL instance
2. RDP client.
3. HTML5 server
4. Built-in web-server that runs on port 81 as default

Now let's assume some browser requests some page on port 443 or 80, the port unificator notices it and forwards the request to port 81 where the built-in web server listens and servers the .html pages.
Afterwards the browser creates websockets connection on port 443 or 80, the port unificator notices it and forwards the request internally to the html5 server, it get's not sent to other instances, it gets processed internally.

The html5 server gives the user the choice to use IIS or Apache as third server, so that it get's used instead built-in web server (position 4.), but your IIS should listen on port 81 and not on already taken by html5 server ports 80/443, so that any http request processed on port 80/443 gets forwarded to port 81 where your IIS listens.

That what you did, you started your IIS on port 80/443, and IIS does not support Websockets connections. It will serve for you .html pages but when Websockets request arrives on port 80/443 than IIS does not know what do with this request, therefore the client side has firstly tried to create Websockets connection than after failure XHR connection, and than timed out.
In fact you removed the server side html5 server and that was the fault.

Always have in mind, the html5 server has to be first in chain and IIS the next one.
In this configuration the SSL role takes always the html5 server, so the certificate has to be converted to jks format and run with html5 rather than processed by IIS.

We are having the exact same problem.

Could you explain how you would accomplish what you are talking about in regards to forcing the html5 server to be "the first in the chain?"

Also, how would we convert our server 2012 self-signed cert to jks?

Hello,

Have you checked our online documentation regarding this subject ?

terminalserviceplus.com/docs/using-iis