WS2008: Terminal Server Web Access Architecture

It’s Day Twenty-Three of our series.  The Launch Event is just a couple of days away.  Following on from yesterday’s post on Terminal Services RemoteApps, today we’re going to be providing a very brief overview of the Architecture of Terminal Server Web Access and the Web Connection Client.

As we showed you yesterday, after installing TS Web Access, a default page is included that users can use to find and launch RemoteApps.  The page consists of a frame and a customizable Web Part.  This Web Part can be incorporated into a Windows Sharepoint Services site as well (but this is not something that we’re going to cover).  TS Web Access works with Terminal Server RemoteApp to publish applications to end users, as we saw yesterday.  The published applications are actually add-ins that are handled by the ActiveX control installed by default with the RDC 6.x client.  By default, when TS Web Access is installed, the TS Web Access site installs to the Default IIS Web Site (to the /TS virtual path).  The Remote Desktop Web Connection site is also installed to this same path.  The installation path and client files are located in %windir%\web\ts.  To connect to the TS Web Access page, use Internet Explorer and navigate to http://<servername>/ts where <servername> is the name of your TS Web Access server.

So what happens when a user clicks on a published RemoteApp program in TS Web Access, or even if they double-click a published RemoteApp program on their desktop?  The first thing that occurs is that the Terminal Services ActiveX control (mstscax.dll) creates a temporary .RDP file in the users’ %temp% folder.  This .RDP filename will start with TSPORTAL# followed by a random 5-digit number – such as TSPORTAL#19283.rdp.  The ActiveX control calls MSTSC.EXE and passes the location of the temporary .RDP file as a parameter – for example: mstsc.exe /web/ webfilename:%userprofile%\AppData\Local\Temp\TSPORTAL#19283.rdp.  The RDC Client application is launched and executes the temporary .RDP file.  A Terminal Server session is created on the Terminal Server that is specified in the .RDP file, and the specified RemoteApp starts on the Terminal Server.  The RemoteApp is presented to the user in a standalone window that represents their Terminal Server session – and the temporary .RDP file is deleted by MSTSC.EXE.

Let’s switch focus now, and discuss the Terminal Services Web Connection client.  This client is installed with the TS Web Access Role Service.  The installation path and client files are located in %windir%\web\ts.  The site uses Desktops.aspx to call the ActiveX control, mstscax.dll,  which launches a Remote Desktop session on the Terminal Server from within Internet Explorer.  So why would you use the Terminal Services Web Connection client?  The most common scenario involves users who are away from their normal workstations.  They can use Remote Desktop Web Connections to gain secure access to their primary workstation or preferred Terminal Server from any computer running Windows and Internet Explorer.  Furthermore, the administrators can customize the pages and use scriptable interfaces associated with the ActiveX controls to customize their users’ experience.  The client files are copied to the %windir%\Web\Ts\En-US directory on my server running US English.  The included sample Desktops.aspx page can be used as-is or modified to meet particular needs.

The installation process itself involves a straightforward file copy from the Windows staged media to the target folder on the server (%windir%\Web\ts) and web sharing is programmatically enabled on the directory.  The ACL’s are set as follows:

  • Administrators: Full Control
  • Users: Read & Execute

Users are presented with the following interface when choosing the Remote Desktop option from the TS Web Access page:


As you can see, the options largely mirror the options in the full Remote Desktop Connection client, with the exception that the user cannot customize the performance options (such as bitmap caching etc) – they have to select one of the canned performance templates.

And with that, Day Twenty-Three draws to a close.  Tomorrow we’ll take a look at Terminal Server Session Broker.  Until next time …

CC Hameed

Share this post :