Freigeben über

How TSWeb / TSAC / Remote Desktop Web Connection Client Works

  • Artikel

[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
https://support.microsoft.com/?id=270897

See also
294720 How to Server Publish a Terminal Server with ISA
https://support.microsoft.com/?id=294720

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.

Comments

  • Anonymous
    March 19, 2004
    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...
  • Anonymous
    March 19, 2004
    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...
  • Anonymous
    April 05, 2004
    whassssssup
  • Anonymous
    April 06, 2004
    Try the Citrix Secure Gateway...much safer!!
  • Anonymous
    April 13, 2004

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.

  • Anonymous
    April 13, 2004
    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.
  • Anonymous
    April 29, 2004
    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?
  • Anonymous
    April 29, 2004
    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.
  • Anonymous
    April 29, 2004
    The comment has been removed
  • Anonymous
    May 04, 2004
    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?
  • Anonymous
    May 05, 2004
    Instead of specifying the port as part of the server name, the SDK points to it being available as part of the AdvancedSettings2 property.
    http://msdn.microsoft.com/library/en-us/termserv/termserv/remote_desktop_activex_control_interfaces.asp

    So you should be able to set rdpclient.AdvancedSettings2.RdpPort = 3391 before launching the connection.
  • Anonymous
    May 25, 2004
    só um teste
  • Anonymous
    May 29, 2004
    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
  • Anonymous
    May 29, 2004
    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.
  • Anonymous
    June 08, 2004
    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 ...is it going to work ?
  • Anonymous
    June 08, 2004
    You could change the listening port, but then you'd not be able to run other services on 80 or 443 - IIS (or possibly Web Publishing) might fail if something else grabs its port.

    So, changing TS port possible, but probably not so good in the long run (especially if you have to go through an HTTP proxy to get out, in which case it'll fail anyway).
  • Anonymous
    June 08, 2004
    i'm going out thrue a proxy.
    So i'll have to wait RDP over HTTPS with WS2003 R2 .....cool !
  • Anonymous
    June 10, 2004
    Can i use the web connection with 2 or more conecctions at the same time?
  • Anonymous
    June 10, 2004
    As long as you're connecting to a Terminal Server and it's been configured to allow that, I can't think of a reason why not.
  • Anonymous
    June 30, 2004
    is it possible to pass proxy username and password to the activex via parameters in order use RDP over port 80?
  • Anonymous
    June 30, 2004
    Not as far as I know.
  • Anonymous
    July 12, 2004
    It would seem that the windows explorer behaves sluggish when "browsing" local resources over a Remote Desktop session.
    The performance is much snappier from the command prompt using \tsclientc. Could this be as a result of explorer enumerating the files in the folder in some "extensive" way. I also noticed that the "Send to" is also very sluggish when using the Remote Desktop session if when local disk access is enabled.
  • Anonymous
    July 12, 2004
    Yes - Explorer has significantly more on-wire overhead than using CMD - plus - you're squeezing (what I think is) SMB traffic over the same TCP socket you're using for display upates (and any other RDP features), increasing latency a little more. It's not going to be on a par with "real" drive sharing on a low-latency link (latency is the killer, more than bandwidth for this scenario), but for users that only have TS access, it's pretty good.
    I haven't noticed Send To being sluggish before, I'll try it next time I'm RDPing with mapped drives (not often).
  • Anonymous
    July 13, 2004
    Just for giggles - I arranged the folowing test - two computers on same router. Then use TS from one to other. The disk access via TS is much slower than when via plain net share access. I wonder if the disk resource thottleing could be the culprit. If I transfer I large file via net share - it hogs the network and make RDP sluggish. If I transfer via TS - the RDP session is responsive and the transfer takes a little longer as expected - which is good. Could this BW throttleing however be causing explorer to suffer ? Sorry for seeming to be persistent. I am betting a major project on TS and I would like to know the variables. Thanks.
  • Anonymous
    July 13, 2004
    Is it possible to make a link or TSWEB specifically connect to a server and not give the user the option of entering a server name?

    Thanks, Chris
  • Anonymous
    July 13, 2004
    Razeez- I guess it could be disk throttling, but I've not heard of that before. My thinking (which may be incorrect) is as follows:
    - explorer is sensitive to latency, because it's quite "chatty" (take a network trace of browsing a share on your test network)
    - SMB is also sensitive to latency
    - When connecting directly to an SMB share, you have a whole TCP connection to try to saturate
    - When connecting to TS and trying to do SMB over the TS session, you're fighting for bandwidth with everything else in the TS session, and TS is geared for screen updates, not file sharing - it's going to be slower, as latency will be introduced: causing the knock-on effect of Explorer being slower.
  • Anonymous
    July 13, 2004
    Chris - sort of - you could customize the sample page to not prompt for a server name, and just have a "Connect" button. Or, you could script the connection in the onload event (I think, haven't tried it).
    There's no tsweb://servername protocol that I know of though, if that's what you're asking.
  • Anonymous
    July 14, 2004
    How do I customize the page so that it only has a connect button and the size option so that when they click on Connect it connects to the server I want?

    Thanks for the info!
    Chris
  • Anonymous
    July 14, 2004
    Some HTML required - find the tag that reads something like:
    <input type="text" name="Server" id="editServer">
    And replace it with
    <input type="text" name="Server" id="editServer" value="myservername">
    for a pre-typed name, and/or change the type to "hidden" to hide the name.
  • Anonymous
    July 14, 2004
    Never mind, I was able to make the server field hidden. Although they could still see it if they viewed the source, this way is quick and dirty :-) Thanks for your help and great info!
  • Anonymous
    July 15, 2004
    I installed Server 2003 and enable RDP web. All of the local workstations are set up for remote connectivity with permissions set. The firewall has ports 80 and 3389 forwarded to the server. When I get to the tsweb page and try to connect to a local computer, it says that it can not be contacted. What am I doing wrong?

    Thanks.
    Bob
  • Anonymous
    July 15, 2004
    In general terms: Try using the regular TS/RDP client to connect rather than tsweb - if it too doesn't work, you need to work out what's wrong there first.
  • Anonymous
    July 15, 2004
    The way I am doing it should work, correct? I will test it the other way. Do I need to enable RDP web on the desktop computer as well? I only have it on the server at this point. I am trying to connect through the server to the desktop. Thanks!
  • Anonymous
    July 16, 2004
    The Web part is just enough to run the client- it's the RDP part that's important. If you can do what you want through the "regular" client, the web client should work identically.

    I'm not quite clear on what you're trying to do, so here's what I think is most likely: If you're trying to connect from the server itself, yes, it should work. If you're trying to connect from outside the firewall, you'll only be able to connect to the computer you've forwarded 3389 to, by specifying the external IP of the firewall.

    To do more computers with a single IP address, your firewall needs to do PAT, so you can publish each internal PC on a different external port. Then, you connect using (external IP of firewall):(port) eg www.example.com:3390 for desktop 1, 3391 for desktop 2, and so on (port numbers are arbitrary here).

    Essentially, it's the same as dealing with any other NATted service; the usual rules'o'NAT apply.
  • Anonymous
    July 23, 2004
    (comment spam deleted)

    Comment spam again
    Comments bring me happiness
    Not comment spam though
  • Anonymous
    August 03, 2004
    The comment has been removed
  • Anonymous
    August 05, 2004
    Hello Tristan,

    What I had like to know is: if I'm at a different location from my LAN, how can I connect to my office computer using remote desktop web connection.

    Been trying to do this without much success
  • Anonymous
    August 08, 2004
    Hi Dele,
    That's what the picture above is trying to explain - you need to be able to connect to the internal computer directly, and you'll need to jiggle your firewall configuration - and the connection page, probably - to do that.

    The easiest way to make sure it'll work is to get the MSTSC client working, then fiddle the web page into doing the same thing.

    The web client doesn't make it any easier to connect from external networks, it just "formalizes" the connection so that you don't have to enter settings into the RDP client directly.