Blog du Tristank

So terrific that 3 of 4 readers rated it "soporific"

How TSWeb / TSAC / Remote Desktop Web Connection Client Works

How TSWeb / TSAC / Remote Desktop Web Connection Client Works

  • Comments 40
  • Likes

[Update 16 Aug 2004] I've posted some sample TSWeb HTM file that handles different ports too, and steps for how to get it working* with ISA 2004 (or other Port Address Translation-capable firewalls) in this post: Publishing RDP (Terminal Servers, XP Remote Desktop) with TSWeb.

There's a common misconception that TSWeb allows you to connect to a Terminal Server over HTTP. The reality is that you just use HTTP to transfer the Remote Desktop Client ActiveX control to the client browser, which then runs and makes a regular RDP connection to the Terminal Server, just like the regular Remote Desktop client would, but presented in a browser window.

Short version: HTTP and RDP are used to connect to a TSWeb server. HTTP (TCP 80) is used to download the ActiveX control, which then connects directly using RDP (TCP 3389) to whatever server is specified by the page for the actual Terminal Server interface. Clients that can't use port 3389 through a firewall won't be able to connect, so clients that exclusively have Web protocol access are not able to use this method to connect. (They'll be able to download the client and the page, but not able to do the actual Terminal Server part).

Long version:

Since the Terminal Services Advanced Client (TSAC), we have offered a web client version of the Terminal Server Client - nowadays called the Remote Desktop Client.

The TS Web client package can be installed on any Web server - it's essentially a CAB file that contains the program itself (the ActiveX control) and some HTML or ASP to display a web page - it's done using standard <OBJECT> tags. The web page is designed to ask your browser to download the CAB file, run the ActiveX control and pass some basic parameters to it, such as the server name and resolution.

There are several possible advantages to this method:

  • You limit the users' need to learn server names - clicking links is all they have to do
  • You can control client settings centrally, from the web server, by editing the HTML page
  • You can upgrade the client software on the server 1

The disadvantages:

  • 1 Non-administrators generally won't have permission to install ActiveX controls. On Win9X, no problem, everyone's an administrator, but on more modern OSs, this can make deployment trickier - you'd have to actually roll out the client via, say, SMS or Active Directory.
  • You need to ensure client connectivity to both the Web server, and the Terminal Server
  • Clients can easily use MSTSC to connect directly to the Terminal Server - by itself, using the Web Client does not increase security because the web server's security settings are not at all related to the Terminal Server security. You need to adjust the properties of the RDP Connection Object in the Terminal Services Configuration MMC to restrict which users or groups have permission to use Terminal Services (and any other security settings you need), just as you would as if the clients were connecting directly to it. Because they are.

And after typing most of this, here's the KB article that also describes how it works...

270897 How Terminal Server Advanced Client Connects to a Terminal Server

See also
294720 How to Server Publish a Terminal Server with ISA

I love it when that happens*.

Helpful Picture:

[Updated 20 May 2004] This Helpful* Picture illustrates TSWeb Publishing when ISA Server 2000 is used - being fairly ISA-centric myself, I figured I'd pop this in. The top one is how you'd probably do it with an Integrated mode ISA Server (if you have routers in front of ISA but use ISA as the primary client connection behind them, then it works for that model too). The other one is how you'd do it if you have a separate firewall doing the NAT/Firewall stuff, and a cache-only ISA Server that publishes your websites.

For the Integrated scenario, you Web Publish the IIS instance hosting TSWeb, and then Server Publish the RDP protocol (you'll need to create an RDP Server protocol definition for TCP 3389 Inbound, no secondary connections).

Quick Bullets:

  • The Web Server doesn't need connectivity to the Terminal Server.
    • Connections are Client -> Web Server and Client -> Terminal Server
  • The client uses RDP to connect to the TS, not HTTP
    • so the client can't connect if it only has Proxy connectivity (eg, just 80 and 443)
    • the server doesn't proxy the client connection
      • you can't connect to random servers on the internal network through the server - the client computer needs to be able to directly access the internal machine, or a port forwarded to the internal machine
      • OK, so technically you can access it using the RDP client through the server again , but a) that's cheating and b) you're adding more overhead, so it's probably not the best idea
  • You need one external IP Address and port combination per internal server
    • if you have multiple TSs or WinXP Pro machines and only one IP address, use PATto forward from different external ports to 3389 on the internal machine.
      • eg, external IP:3390 -> Internal Desktop: 3389
      • using the out-of-box web client, this needs to be scripted using AdvancedSettings2: rdpclient.AdvancedSettings2.RdpPort = 3390 before connecting...
      • But as it happens, if you'd rather not fiddle with VBscript, this was the subject of Publishing RDP (Terminal Servers, XP Remote Desktop) with TSWeb , which links to a generic connection page I fiddled up that allows the user to specify their own port,

If you liked this, you'll also love TS Licensing in 90 Words Or Less and Publishing RDP (Terminal Servers, XP Remote Desktop) with TSWeb.

  • This is a common complaint we see in the public newsgroups... People think that the webclient will allow use without forwarding the appropriate port for Remote Desktop and that it will allow connections over a proxy...

    Still better yet is the belief that the web client will allow connections to machines behind a NAT firewall from the internet without having to forward the ports/set up a VPN...

  • I think it's understandable - I think when something's called a "web client", it creates certain assumptions in the mind of the reader.

    Which reminds me of the next topic I was going to cover...

  • whassssssup

  • Try the Citrix Secure Gateway...much safer!!

  • # re: How TSWeb / Remote Desktop Web Connection Client Works 3/19/2004 12:29 AM Jeffrey Randow
    This is a common complaint we see in the public newsgroups... People think that the webclient will allow use without forwarding the appropriate port for Remote Desktop and that it will allow connections over a proxy...

    Still better yet is the belief that the web client will allow connections to machines behind a NAT firewall from the internet without having to forward the ports/set up a VPN...


    yes, i was under the assumption that this web client would make that possible (without actually thinking it through first, of course). the only server i could get to behind my NAT firewall was the one i was forwarding ports to, so now it's back to the VPN connection to get from work to the home network.

    i thought tsweb was going to be pretty cool upon first glance, but in reality, it's quite useless to me.

  • Yep, it doesn't do what you want it to do. It's still useful for many situations, but it's not a NAT bypass solution, just an ease-of-use-and-central-administration solution.

  • Having some problems. I have the activeX. I can pull up the page but I can't log in. Keeps saying the computer cannot accpet connections. Can connect inside the network. Firewall not configured right maybe? Any HELPFUL comments?

  • Check the second KB article listed in the text above; it walks you through it.

    Essentially, you need to server publish port 3389 from an internal server; this will work in Firewall or Integrated modes of ISA.

  • One other thing I forgot to mention - the client uses whatever IP Address or DNS name is specified on the web page to connect to the target server.

    When you're connecting from the Internet, you may need to add another entry that maps to the public IP address of the ISA Server.

    So, Server (Internal) might be, but Server (Internet) needs to resolve to 203.x.y.z .

  • Could you use ssh tunneling with TSWEB? I've tried to forward local port 3391 to my Win2k server port 3389 using ssh (the tsweb page is served via the public website), but when I enter the server name as "localhost:3391" I get an error warning in IE. How do you specify which port to connect to? Do I need to modify the HTML, and if so, what do I change?

  • Instead of specifying the port as part of the server name, the SDK points to it being available as part of the AdvancedSettings2 property.

    So you should be able to set rdpclient.AdvancedSettings2.RdpPort = 3391 before launching the connection.

  • só um teste

  • hi i was just wondering what would be the consequesnces if u connected through a remote web connection using the web browser, will your ip address be sent to the server your are connecting to or will the remote dektop websites ip address be sent to the server???
    regards Johnson

  • The client always connects directly to the Terminal Server. Think of the web page as being like a batch file that starts the Remote Desktop client, pointed at whatever IP address is specified.

    The Web Server doesn't need any type of connectivity to the TS.

  • I'd like to know something.
    The TSWeb is working fine for me. But when my client is behind a firewalled/proxyed environment ... i can't access the computer (only 80 and 443 are opened). If i change the listening port thrue registry it going to work ?