Even though launching Terminal Server connections that are embedded into a web page is easy to do, there are some technical limitations. The default web page is limited to desktop connections, and this can be a problem if you've decided to have users launch individual applications instead of full desktops.
Instead of using the embedded ActiveX control, you can build custom web pages that have links to individual applications. You'll remember from Chapters 5 and 10 that it's possible to create an "RDP" file containing Terminal Server application connection settings. You can then deploy this RDP file to your users.
Take this process one step further in order to launch an application from a web page by placing links to RDP files within your web pages. By combining a little bit of HTML, an RDC client, and some preconfigured RDP files, you can create a portal-friendly HTML list of Terminal Server applications for a centralized location from which users can access Terminal Server applications. One URL can host links to applications for the entire environment, regardless of where your Terminal Servers are located.
Similar to using embedded ActiveX RDW client, there are three key components to consider when designing web pages that launch RDP applications:
The web server serves the HTML pages to the end user. In this case, the web server can be just about any platform.
To be able to launch RDP Terminal Server sessions this way, the client device must have the full RDC client installed locally. In theory, any platform can be used, so long as the client's operating system is capable of receiving RDP files and automatically passing them on to the RDC client software.
RDP files stored on the web server contain all the connection information for a particular application. They're passed down to the client device when requested. From there, the client's browser passes them on to the locally installed RDC software to launch the RDP session.
As in all web-based scenarios, the Terminal Server in this case is essentially a bystander. It's not involved in the web server or application launch process, rather, it only receives the users' RDP sessions once they receive the RDP files from the web server.
Getting this all to work is more complicated than when working with the embedded ActiveX RDW client. However, the extra configuration time on the front end makes the whole experience easier for your users.
Figure 11.2: The process of launching RDP applications from a web page
The user enters a URL into their browser
The web server sends down an HTML with a list of applications available in the Terminal Server farm. Each application is linked to an RDP file.
The user clicks an application icon or link.
The web browser requests the file from the web server.
The RDP file that is stored on the web server is downloaded to the user's client device.
The user's client device has a file association for the RDP file type that launches the RDC client and receives the RDP file.
The RDC client establishes a session to the application or server based on the preconfigured settings in the RDP file.
The user authenticates to the server and the application or desktop session is launched.
At first glance, this process may seem complicated. However, if you take a logical look at it, you'll see that it is probably something you do every day by clicking on web links to PDF files. If you click a link within a web page to open a PDF file, the PDF is sent to your machine and opened using your Adobe Acrobat reader. The same happens here, except instead of a PDF and Adobe Acrobat, you have an RDP file and the RDC client.
The only configuration change that you'll need to make to your web server will be to register RDP as a MIME type. We'll review this process for IIS, but it will need to be done to your web server regardless of its type.
By default, IIS servers only host and serve files to users that are of a registered MIME type on the server. Since an RDP file is unknown to the IIS server, it must be registered or it won't be served to clients. In IIS 6.0 running on a Windows 2003 server, do this by the following procedure:
Using Internet Service Manager on the web server, locate the website you wish to configure for use with the RDP client. (This may be the default website if you're using a test server.)
Right-click on the web site and select properties.
Select the "HTTP Headers" tab.
Click the "MIME Types" button at the bottom of the page.
Click the "New" button on the right.
In the new MIME type window, enter ".RDP" as the Extension (without quotes) and "application/x-rdp" as the MIME type (without quotes).
Click "OK" on each of the three open windows until you are returned to the main Internet Services Manager window.
If you're using another type of web server, the main difference is that ".RDP" is the file extension and "application/x-rdp" is the MIME type.
The basic web page you need to make consists of a few hyperlinks to RDP files. This page is so simple that it can be made in FrontPage or notepad in a just a few minutes. "Jazzing up" the web page should not be a problem for even a novice with no web programming skills.
The webpage is generally made after the RDP files are created, but for the purposes of continuity we'll step though this first assuming that you learned something about RDP files in the client chapters of this book.
The sample code below was created in Microsoft FrontPage and is a functional RDP Application list:
<html> <head> <meta name="GENERATOR" content="Microsoft FrontPage 5.0"> <meta name="ProgId" con- tent="FrontPage.Editor.Document"> <meta http-equiv="Content-Type" content="text/html; charset=windows-1252"> <title>New Page 1</title> </head> <body> <p>This is a sample RDP app portal….</p> <p><a href="excel.rdp">MS Excel 2000</a></p> <p><a href="winword.rdp">MS Word 2000</a></p> <p><a href="outlook.rdp">MS Outlook 2000</a></p> </body> </html>
As you can see, the HTML links to three RDP files. Since the web server is now configured to host RDP files, all that's required to "deploy" this solution is to copy the RDP files and this HTML file to the web server. A screenshot of the web page this code produces is on the next page.
If you're the creative type, the web pages can be reconfigured into any format with any look and feel (also shown on the next page).
Figure 11.3: A quick application launching webpage made with FrontPage
Figure 11.4: A more sophisticated looking webpage based on the same basic code
At its basic level, the web page is nothing more than a mechanism providing links to RDP files. To enable users to launch specific applications, you must create the RDP files that will make up the list.
As you'll recall from Chapter 10, an RDP file is essentially a text file that's created when you save a connection configuration within the RDC client. All of the configuration settings within the client are stored within the RDP for use at a later time. Options stored in an RDP file include:
Address to connect to (IP address, cluster name, or server name).
Client device configuration.
Application to execute in the session.
You'll need to create RDP files for each application. This process is outlined at the end of Chapter 10.
The RDP client on the user's workstation shouldn't require any configuration other than making sure it's installed. (Chapter 10 details client distribution and installation options.)
In order for users to launch applications from web pages, they'll need to have the full client installed. The RDW ActiveX control will not suffice because the ActiveX control does not have the file type association support that the full RDC client does and cannot run outside of a browser window as can the full RDC client.
Most people add an "Install Client Now" link to their web pages that leads to an MSI package to install the client on the user's workstation.
All that's left to address on the client device is that the first time the user clicks an RDP web link, a "Save or Open" dialog box will appear asking the user what he wants to do. The user can click "Open" and "Do not prompt again for this file type," but that might be confusing for them.
Get around this by editing the registry of the client device. Most people make the registry modification at the same time that they install the RDC client. (For Windows XP workstations that have the RDC client preinstalled, you'll need to modify the registry via a logon script or SMS package.)
Can create a .REG registry merge file from the following text (or visit www.brianmadden.com to download this file):
REGEDIT4 ; removes the prompt to download the RDP file. [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Applications\msts c.exe\shell\Connect\command] @="mstsc.exe \"%l\"" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Applications\msts c.exe\shell\Connect] "MUIVerb"="@C:\\WINDOWS\\system32\\mstsc.exe,-4002" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Applications\msts c.exe\shell\Connect] @="Connect" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Applications\msts c.exe\shell\Edit\command] @="mstsc.exe -edit \"%l\"" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Applications\msts c.exe\shell\Edit] "MUIVerb"="@C:\\WINDOWS\\system32\\mstsc.exe,-4003" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Applications\msts c.exe\shell\Edit] @="Edit" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Applications\msts c.exe\shell] @="Connect" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\RDP.File] "EditFlags"=hex:00,00,01,00 [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentV ersion\Explorer\FileExts\.rdp\OpenWithList] "a"="mstsc.exe" [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentV ersion\Explorer\FileExts\.rdp\OpenWithList] "b"="IEXPLORE.EXE" [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentV ersion\Explorer\FileExts\.rdp\OpenWithList] "MRUList"="ab" [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentV ersion\Explorer\FileExts\.rdp\OpenWithProgids] "RDP.File"=hex: [HKEY_CURRENT_USER\Software\Microsoft\Windows\ShellNoR oam\MUICache] "C:\\WINDOWS\\system32\\mstsc.exe"="Remote Desktop Connection"
Once you complete all these steps, you'll have a custom application list that you can plug into any portal or simply use on its own for deploying Terminal Server applications to your end users.
People who are familiar with third-party Terminal Server products point out a major drawback to the web techniques outlined in this chapter. Specifically, both of these techniques lack the ability to automatically create custom application lists for each user.
For example, wouldn't it be great if your users could log in to a website and then get a custom list of applications that was created just for them based on their group memberships? Actually, there are three ways to achieve that:
Use a third-party product.
Write a custom ASP page.
Use Windows SharePoint Services.
The first involves the use of third-party products. These products are fully discussed and reviewed in the Appendix of this book, but Citrix MetaFrame, Tarantella New Moon Canaveral iQ, and Jetro CockpIT all have web portal capabilities that can do just this.
Second, some developers have taken the time to build ASP pages that automatically show or hide links to RDP files based on a user's group membership. Such an ASP page is simple to program for even a beginning ASP programmer.
The final method, and by far the most popular for pure Terminal Server environments, is to use Windows SharePoint Services, or "WSS." WSS is available for free with Windows Server 2003, and is the newest version of Microsoft's SharePoint technologies that were first available with SharePoint Team Services and SharePoint Portal Server 2001.
WSS is a content and document management system allowing administrators to "publish" content for various audiences based on various group memberships. Using WSS, you can publish RDP files as content, and target them for specific groups. For example, you can create a domain group called "Word Users" and then publish an RDP file that launches MS Word to that domain group. Upon logging in to the portal web page, users in the Word Users group would see the RDP file, and users who weren't in the group wouldn't.
More information about using Windows SharePoint Services to create dynamic web application portals for Terminal Server environments is available at www.brianmadden.com.