Thoughts from the EPS Windows Server Performance Team
Useful Microsoft Blogs
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:
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
PingBack from http://www.ditii.com/2008/02/23/windows-server-2008-terminal-server-web-access-architecture/
is there a way to delegate permission especially for RemoteApps defined applications like for Citrix?
example: 3 applications are delegated to 3 differently created active directory groups?
comments and ideas are welcome.
No, you would need an application like Ericom PowerTerm WebConnect to provide AD assignments.
It is really a nice article.
I have a question. As If we deploy this on servers, what are client's prerequisite ? Are they have to have vista as operating system ?
Do you know if there is anyway to configure the option "connect to" so users don't have to put the computer name.
I've tried this:
(working on Windows 2003)
Yes, we really should have a list of available computers a la RWW. Otherwise, TSWA is a step backwards.
a late reply -
did you find the solution for having the server name pre-filled in as computer name or a list of available computers a la RWW as suggested above?
Just to piggy back on the last three comments. Is it possible to auto populate the servername on the TSWeb page?
We are using the remoteapp for Dynamics AX. Currently, the application will not logoff idle users. TS picks up mouse movement in local applications and will not close the idle remoteapp. Can anybody assist?
In regards to accessing Remote Applications, where in Active Directory, and which properties will the permission assignments normally be stored?
hi, is it possible to display selected applications for each user on the TS web access portal?
i want to know can i install internet explore 6-7 in ts web access in windows server 2008 web app or not can any body know about that will please help me