Publishing Terminal Services and the TSAC Client – Updated

Publishing Terminal Services and the TSAC Client
By Thomas W Shinder

Get the Book!

For more information about Windows Terminal Services, please visit

One of the most popular features included with Windows 2000 is the Terminal Server. The Windows 2000 Terminal Server allows multiple clients access to the Terminal Server and have each client run its own session. This is unlike remote control solutions such as PCAnywhere or VNC, where a single administrative session is established with the destination server. The Windows 2000 Terminal Server allows even the lowliest of 486SX-20 machines with 8 MB of RAM running Win 3.x to run a Windows 2000 Terminal Client session.

When Windows 2000 first arrived, the only way to connect to a Terminal Server was through the Terminal Server client software. This software can be installed over the network or by using a set of floppy disks. While the actual installation is simple, network connectivity issues were sometimes a hassle, and lugging a floppy disk set around to 2500 machines is not time well spent.

In order to widen the availability of Terminal Services to virtually all machines, Microsoft developed the Terminal Services Advanced Client (TSAC). The TSAC software installs on an IIS Server and adds functionality to the web server. This added functionality allows it to accept requests from browsers to access the Terminal Server. When an IIS website it updated with the TSAC web software, a user can connect to the web site and run a Terminal Client sessions within his web browser.

Obtaining and Installing the Terminal Services Client

You need to install the Web Package component of the TSAC software onto the IIS Server. This IIS Server should be the same machine that is running the Terminal Server. You can find the Web Package software at the Microsoft web site, or on the Windows 2000 Service Pack 1 CD-ROM. If you are installing from the CD, search for the file tswebsetup.exe and run it from the CD. If you don’t have the CD (and who does?), download the Web Package at:

Just double click the icon for the program and follow the simple instructions. There’s nothing there for you to mess up.

Preparing the Network

As always, you must prepare the network to support ISA Server publishing. The following network services and configuration options should be in place before beginning the publishing effort:

  • NetBIOS name resolution infrastructure is in place (WINS)
  • DNS host name resolution infrastructure is in place
  • WINS and DNS server settings on the internal interface of the ISA Server are configured
  • IIS is running on the internal Terminal Server to be published
  • The internal IIS/Terminal Server is configured as a SecureNAT client
  • Authentication and Security Issues are considered

  • You must address each of these issues before beginning your TSAC publishing effort. For a more complete review on publishing, be sure to check out my two part series on publishing a Web Server at

    WINS Architecture

    Even though Windows 2000 is not dependent on NetBIOS, there is a lot of legacy code still living on most production networks. While most of the core network functionality of Windows 2000 is independent of NetBIOS, there are still some network utilities and services that are dependent on NetBIOS name resolution. If you don’t have your NetBIOS name resolution architecture in place, you’ll run up against problems sooner or later. And some of those problems may be difficult to troubleshoot.

    Depending on the size of your internal network, you need at least one WINS Server. The WINS Server can be installed on any machine on the internal network. Name Registrations and Queries are not authenticated, and therefore the WINS Server can be in the same domain, in a different domain, or on a stand-alone server. It does not matter at all. Just make sure that the WINS network is configured properly and that WINS clients are configured to use the appropriate WINS Server.

    DNS Architecture

    If there is one issue that ruins good ISA Server configurations, that issue is the lack of a coherent DNS infrastructure on the internal network. You will save yourself a lot of work if you install and configure at least one DNS server on your internal network. The ISA Server often needs to use host names when connecting to a server on the internal network. If you don’t have an internal DNS server, ISA Server will waste a lot of time with unsuccessful attempts at resolving host names.

    Actually, the ISA Server really doesn’t need to know the host name of the internal server that you’re publishing. Remember that you can also use IP addresses in your Web Publishing Rules. However, if you use an IP address to denote the internal web server, you might run into the dreaded 14120 error when internal clients attempt to connect to the internal server. While this in no way will completely rid you of the dreaded 14120 error, and will reduce the number of bogus Application Log entries.

    I therefore highly recommend that you design, install and configure your DNS infrastructure before even getting near ISA Server. There are some helpful tips and tricks on how to do this at If you are not proficient with DNS, you need to be. Check out and know it cold!

    WINS and DNS Server Settings on the ISA Server

    Make sure the ISA Server is configured to use a WINS and DNS Server on your internal network to resolve NetBIOS and DNS host names on the internal network. You also need to configure the ISA Server to resolve Internet host names as well.

    One approach to doing this is to enter on the internal interface of the ISA Server the address for a WINS Server closest to the ISA Server. For host name resolution, you can enter the internal DNS server’s IP address and an external DNS server IP address. Make sure that the internal DNS server’s IP address is on the top of the list of DNS servers. This configuration should optimize the performance of host name queries.

    IIS and Terminal Services are Installed and Configured

    Publishing a TSAC Server requires that you have both Terminal Services and IIS installed on the same machine on the internal network. While there may be programmatic solutions to allow the TSAC extensions to connect to other servers on the network, I don’t know about them, so I won’t try to discuss them here.

    Make sure the WWW service is running on the internal IIS server and that it is listening on Port 80. While you might be able to use an alternate port number, there is no information on whether or not this is supported, and I have not tested this configuration.

    After confirming that the IIS WWW service is properly configured, check for the Terminal Services installation. If Terminal Services is installed, make sure that you use at least medium security so that information is encrypted in both directions. Low security encrypts data only going to the Terminal Server and does not encrypt data coming from the Terminal Server.

    If you only need administrative access to the internal Terminal Server, install Terminal Services in Remote Administration mode. If you want users to connect to the Terminal Server and run applications on it, then install it Application Server mode. Note that if you install the Terminal Server in Application Server mode, you will need to install a Terminal Services Licensing Server to support the non-Windows 2000 clients that will connect to the Terminal Server.

    Internal IIS/Terminal Server is Configured as a SecureNAT Client

    Remember to make the IIS Server a SecureNAT client so that you can use Web Publishing and Server Publishing rules. Do not make the web server a Firewall client. This is an easy step to forget when you working on publishing your TSAC site. Don’t forget to do this!

    Authentication and Security Issues

    Terminal Service connections are secure. Username and password information is not exchanged in clear text. You can confirm this for yourself by using Network Monitor and listening to the interchange between the Terminal client and server. However, keep in mind what I said above regarding data encryption.

    If you plan to secure the TSAC web site, remember that the Web Proxy service does not pass Integrated or Digest Authentication. There was a question about whether or not the Web Proxy service passes Digest Authentication. I have tested this to confirm that it does not. However, if your experience differs, please write to me so that we can clear up this issue.

    The best configuration for the TSAC web site is to allow anonymous access to the web site and configure authentication with the Inbound Web Requests listener on the ISA Server. Do not use basic authentication as it passes username and password information in clear text. You should use either Integrated or Digest Authentication on the external interface. Be aware that Digest Authentication is limited to Windows 2000 domains.

    The users will have to enter a username and password combination before accessing the Terminal Server. Since this information is not passed in the clear, this should represent adequate security when combined with authentication required on the external interface of the ISA Server.

    Publishing the TSAC Site

    To make the TSAC web site and services available to clients via the web browser, you have to configure one Web Publishing Rule and one Server Publishing Rule.

  • Web Publishing Rule publishes the internal IIS Server
  • Server Publishing Rule publishes the Terminal Server

  • After configuring both the Web Publishing and Server Publishing Rules, the clients will be able to connect to the Terminal Server through their browsers.

    Creating the Web Publishing Rule

    You must create the Incoming Web Requests listener before you create any type of Web Publishing Rules. Check out other articles on the site, or better, read the chapter on publishing Web services to the Internet in the Configuring ISA Server 2000 book.

    Perform the following steps to create the Web Publishing Rule:

    1. First, you need a Destination Set for the Web Publishing Rule. Expand the Policy Elements node in the left pane and right click on Destination Sets. Click New and click Set.
    2. Enter the Name and Description of the Destination Set and then click Add. Click the Destination option button, and type in the FQDN that external users will use to access the TSAC site. For the path you can enter /*, but it doesn’t seem to make much difference. Note that if you wish to publish other sites on the same server, you may want to include the path /TSWeb. Click OK and then click OK one more time. When you’re done your set will look something like that seen below.

    1. Expand the Publishing node and then right click on Web Publishing Rules. Click on New and then click Rule.
    2. On the Welcome page, type in a name for the rule. In this example I will use TSAC Site for the name of the Web Publishing Rule. Click Next.
    3. On the Destination Sets page, in the Apply this rule to drop down list box select the Specified destination set option. In the Name drop down list box, select the name of the Destination Set you created for the site. It should look something like what appears below. Click Next.

    1. On the Client Type page select the appropriate client type that you wish to apply the rule to. In this example, we’ll allow Any Request, since access control will be determined by username and password credentials at the Terminal Server. Click Next to continue.
    2. On the Rule Action page, enter the FQDN or NetBIOS name of the internal server after selecting the Redirect the request to this internal Web server (name or IP address). Leave the ports numbers at their defaults. You may want to use the Host Headers option if you are using host headers to configure site redirection on the IIS server itself. You dialog box should look like what appears below. Click Next.

    1. On the last page of the Wizard, review your settings and click Finish.

    If you published the site without using a path, you can test the rule by connecting to the root web on the server. If you used the /TSWeb path, you will not be able to connect to the root web. You might want to create a second rule that uses a Destination Set that includes the root web and then test connectivity to the site. Note that you should change the order of the rules so that the rule that uses /TSWeb Destination Set is above the rule that users a path that allows access to the root web.

    Creating the Sever Publishing Rule

    After the web site has been successfully published, the next step is to publish the Terminal Server. Perform the following steps to publish the Terminal Server.

    1. Before creating the Server Publishing Rule for the Terminal Server, you need to create a Protocol Definition to support the rule. Expand the Policy Elements node in the ISA Management console and right click on the Protocol Definitions node. Click New and then click Definition.
    2. On the Welcome page, type in a name for the Protocol Definition. In this example, I’ll call it Terminal Server. Note that Protocol Definitions that have the primary connection set as inbound can be used in Server Publishing Rules. Click Next.
    3. On the Primary Connection Information page, type in 3389 for the Port number, TCP for the Protocol type and Inbound for the Direction as seen in the figure below. Click Next.

    1. On the Secondary Connections page select the No option button and click Next.
    2. On the last page of the Wizard, confirm your selections and click Finish.
    3. Expand the Publishing node in the ISA Management console and right click on the Server Publishing node. Click New and click Rule.
    4. On the Welcome page, type in a name for the rule. In this example I’ll call it Terminal Server. Click Next.
    5. On the Address Mapping page, type in the IP address of the internal server and the External IP address on the ISA Server. If you have multiple IP addresses bound to the external interface of the ISA Server, make sure to select the one that resolves to the FQDN that users will use to connect to the server. Click Next.

    1. On the Protocol Settings page, click the down arrow for the drop down list box and select the Protocol Definition for the Terminal Services Protocol that you created earlier. Then click Next.
    2. On the Client Type page, select the client type to which you want this rule applied, and then click Next.
    3. On the final page of the Wizard review you setting and then click Finish.

    Testing the TSAC Connection

    Now that both publishing rules are in place, we can test the viability of our TSAC site publishing scheme. Perform the following steps to test the site:

    1. Open Internet Explorer and type in the URL http://destination_name/TSWeb and press ENTER.
    2. You will see what appears in the figure below. In the Server text box, type in the IP address or FQDN that resolves to the IP address that you used in your RDP Server Publishing Rule. Click the Connect button to continue.

    1. The first time a machine connects to the TSAC site, you will see the Security Warning dialog box as seen below. Click Yes to download the TSAC client software. The software will install automatically.

    1. An interesting dialog box appears next. If you choose to have the client appear in Full Screen mode, you will likely see the dialog box seen below. This is a curious dialog box because it’s not clear exactly what security settings it’s referring to. I have tested the security settings on Internet Explorer by setting them as the lowest possible security, but the dialog box still appears. Perhaps an IE expert will be able to tell us what we should do to get rid of this dialog box. Until that time, click OK to continue.

    1. You will see the Terminal Services log on dialog box as seen below. Type in the appropriate user name and password and click OK.

    1. Your desktop appears just as it does when you use the dedicated Terminal Services client, as seen below.


    The TSAC client allows any machine running Internet Explorer to access the Windows 2000 Terminal Server. After reading through the procedures for publishing the TSAC site, it might seem quite simple to get it running. Indeed the procedure is quite easy. However, there are some things to watch out for:

  • Keep in mind that when you type in the Server name in the log on dialog box in the TSAC log on screen, that this name needs to resolve to the IP address of the one you used in the RDP Server Publishing Rule.
  • Remember to make the web server a SecureNAT client. This step is often forgotten, and if you don’t do this before beginning the rest of the process, you might find yourself in an hours long troubleshooting session trying to figure out why it doesn’t work.
  • If you want to require authentication at the TSAC web site, keep in mind that your only option is Basic Authentication. The Web Proxy service will not pass Digest or Integrated Authentication credentials.
  • If you want to improve the level of security, enable authentication on the external interface of the ISA Server. Set the authentication options for the Inbound Web Requests Listener used to listen for the IIS/Terminal Server. You also have the option to enable SSL on the Inbound Web Requests listener.
  • I recommend restarting the ISA Server and the IIS/Terminal Server after the configurations are completed. Try this option if you have manually restarted the services and things still don’t seem to working.

  • Get the Book!


    Terminal Services allow users to connect to a Windows 2000 Terminal Server and run their own user sessions on the machine. This allows users with non-Windows 2000 machines to take advantage of the Windows 2000 operating system and application environment. You can publish a Terminal Server with the aid of the TSAC Web Package. After the Web Package is installed on the IIS/Terminal Server, you can publish both the Web Server and the Terminal Server. This requires one Web Publishing Rule and one Server Publishing Rule. After publishing the Terminal Server, users will be able to use their browsers to connect to the Windows 2000 Terminal Server.

    I hope this article has been helpful and/or interesting to you. If you have any questions on this article, or any insights to add, please post a comment on the message boards, or write to me at [email protected]. I’ll answer your questions as soon as possible. Thanks! –Tom.

    For more information about Windows Terminal Services, please visit

    About The Author

    Leave a Comment

    Your email address will not be published. Required fields are marked *

    This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

    Scroll to Top