Blog du Tristank : How TSWeb / TSAC / Remote Desktop Web Connection Client Works

Hacks

CoWorkers, Present and Past

ISA

Useful*

Archives

How TSWeb / TSAC / Remote Desktop Web Connection Client Works

[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 ¹

The disadvantages:

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

See also
294720 How to Server Publish a Terminal Server with ISA
http://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 PAT to 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.

Posted: Thursday, March 18, 2004 8:59 PM by tristank

Filed under: IT Pro / Sysadmin, ISA Server, Terminal Server, Networking

Comments

Jeffrey Randow said:

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...

# March 19, 2004 12:29 AM

Tristan K said:

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...

# March 19, 2004 10:35 AM

John Large said:

whassssssup

# April 5, 2004 6:00 AM

Xtrix said:

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

# April 6, 2004 11:19 PM

hidden101 said:

# 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.

# April 13, 2004 11:19 AM

Tristan K said:

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.

# April 13, 2004 11:30 AM

Allen Cook said:

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?

# April 29, 2004 2:14 PM

Tristan K said:

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.

# April 29, 2004 2:28 PM

Tristan K said:

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 10.0.0.15, but Server (Internet) needs to resolve to 203.x.y.z .

# April 29, 2004 2:38 PM

Jeremy Sproat said:

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?

# May 4, 2004 11:13 PM

TristanK said:

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.

# May 5, 2004 11:42 AM

silvano said:

só um teste

# May 25, 2004 6:32 AM

Johnson said:

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

# May 29, 2004 6:12 PM

Tristan K said:

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.

# May 29, 2004 11:27 PM

kikistan said:

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 ?

# June 8, 2004 12:10 AM

TristanK said:

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).

# June 8, 2004 12:16 AM

kikistan said:

i'm going out thrue a proxy.
So i'll have to wait RDP over HTTPS with WS2003 R2 .....cool !

# June 8, 2004 4:53 AM

Jose said:

Can i use the web connection with 2 or more conecctions at the same time?

# June 10, 2004 3:09 AM

TristanK said:

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.

# June 10, 2004 12:14 PM

gurel said:

is it possible to pass proxy username and password to the activex via parameters in order use RDP over port 80?

# June 30, 2004 1:41 PM

TristanK said:

Not as far as I know.

# June 30, 2004 1:43 PM

razeez said:

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 \\tsclient\c\. 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.

# July 12, 2004 10:44 AM

TristanK said:

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).

# July 12, 2004 11:21 AM

razeez said:

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.

# July 13, 2004 12:49 AM

krang00 said:

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

# July 13, 2004 8:07 AM

TristanK said:

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.

# July 13, 2004 12:03 PM

TristanK said:

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.

# July 13, 2004 12:06 PM

krang00 said:

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

# July 14, 2004 12:08 AM

TristanK said:

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.

# July 14, 2004 12:38 AM

krang00 said:

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!

# July 14, 2004 12:41 AM

bb1194 said:

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

# July 15, 2004 5:25 AM

TristanK said:

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.

# July 15, 2004 1:06 PM

bb1194 said:

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!

# July 15, 2004 10:57 PM

TristanK said:

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.

# July 16, 2004 1:27 AM

TristanK said:

(comment spam deleted)

Comment spam again
Comments bring me happiness
Not comment spam though

# July 23, 2004 9:07 PM

Paul T said:

Hello!

Im researching to make this work over a ssl connection. is there anyone who has any links of someone trying the same.
so far im trying this:

Using a http load balancer to point to different logon screens. (installed the web-logon.asp on each of the TS servers). Tuned the ActiveX component to use different NAT ports on my firewall. I am still trying to make a certificate approve the PAT'ed connection based on ip/port from the source. (certificate is issued to fw when logon credentials on TS server are ok), and finally finding a wrapper that can forward this in a SSL tunnel back to the client.

Is this way off, or could it be possible? I'm not a MS person and now to wandered in all the Tec groups. I use many different solutions already. (etc. iptables in Linux for NAT/PAT/FW. same for SSL and certificates)

Love the reading on this site, much usefull tips.I only wish MS would release RDP over SSL one year earlier :-)

Thanks.

Paul

# August 3, 2004 10:43 PM

Dele said:

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

# August 5, 2004 8:16 PM

TristanK said:

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.

# August 8, 2004 12:53 AM

Extra Bits That Didn't Fit said:

# August 17, 2004 2:39 AM

David's blog said:

# January 8, 2005 7:26 AM

New Comments to this post are disabled

Blog du Tristank

Recent Posts

Tags

Hacks

CoWorkers, Present and Past

ISA

Useful*

Archives

How TSWeb / TSAC / Remote Desktop Web Connection Client Works

Comments

Jeffrey Randow said:

Tristan K said:

John Large said:

Xtrix said:

hidden101 said:

Tristan K said:

Allen Cook said:

Tristan K said:

Tristan K said:

Jeremy Sproat said:

TristanK said:

silvano said:

Johnson said:

Tristan K said:

kikistan said:

TristanK said:

kikistan said:

Jose said:

TristanK said:

gurel said:

TristanK said:

razeez said:

TristanK said:

razeez said:

krang00 said:

TristanK said:

TristanK said:

krang00 said:

TristanK said:

krang00 said:

bb1194 said:

TristanK said:

bb1194 said:

TristanK said:

TristanK said:

Paul T said:

Dele said:

TristanK said:

Extra Bits That Didn't Fit said:

David's blog said: