Using the Terminal Services through Internet Information Server

Although many administrators think of the Windows Terminal Services primarily as a mechanism for hosting user sessions, it can also be used as a very effective remote management tool. For example, if you need to work on a server that is not in close geographic proximity, you can use the Terminal Services as a way of remotely accessing the server’s console. It’s true that most of Windows Administrative Tools will allow you to manage a remote server, but the Terminal Services have the advantage of allowing you to see the remote server’s desktop. This is advantageous because sometimes there may be an error message displayed on the server’s screen and you would never see the message if you were accessing the server solely through Event Viewer, or one of the many other management tools.

The problem with establishing a Terminal Service session between your machine and a remote server is connectivity. Imagine for a moment that you are at home, in bed, blissfully asleep. The phone rings and wakes you up. You groggily notice that it’s 3:30 AM as the voice on the phone starts explaining to you that there is a problem with a server that’s in an office a hundred miles away.

At this point you’ve got a few choices. You could ignore the call, go back to sleep, and get fired (not a good choice to make). You could road trip it to the remote facility (not fun at 3:30 AM), or you could establish a Terminal Service session with the ailing server. This is where the connectivity issue comes into play. Your company probably has WAN links between the various offices, but that does you no good right now because you are at home. If your company has a VPN, you could establish a VPN connection and then establish a Terminal Service session over the VPN. Another alternative that most people seem to be unaware of however, is that you can interact with the Terminal Services over the Internet.

OK, before I get into the nitty gritty details, let’s stop for a reality check. From a security standpoint, making a Terminal Service session with your servers available over the Internet is probably a bad idea. A Web Based Terminal Service session isn’t completely insecure though. SSL encryption is an absolute requirement and anyone who connects must have a valid set of credentials that are authorized not just to log on, but to log on through the Terminal Services. You can also lock down IIS so that only machines with specific IP addresses are allowed to connect. There are dozens of other things that you can do to make the server more secure, but the thought of being able to remotely control my server through the Internet still makes me a little nervous.

This doesn’t mean that you shouldn’t take advantage of the ability to use the Terminal Services over the Internet though. If you feel comfortable making your server available through the Web then go for it. If you’re like me and you don’t feel comfortable doing that, then you can use the same technique and the same security measures to make the server available across your corporate Intranet.

What good does that do? Well, let’s go back to my earlier example that involved you sitting in front of your computer at home in your pajamas in the middle of the night. Rather than driving to the office or to the remote facility, you could dial into your remote access server at the office and then use a Web browser to establish a Terminal Service session with the Remote facility.

Right now you might be wondering why you would ever go through all that trouble when the Windows Remote Desktop client is actually a Terminal Service client. True, you could dial in and use the Remote Desktop client to establish a Terminal Server session without ever having to install the remote access Web component. Still, there are at least a couple of reasons why it’s a good idea to have the Web component on hand. First of all, the Remote Desktop client comes with Windows XP. If you happen to have an old PC at home that’s still running Windows 98, then your machine won’t have a Remote Desktop client. Another reason for using the Web interface rather than the Remote Desktop client is that depending on how your network is set up, firewalls may prevent you from using the Remote Desktop client. The Remote Desktop client communicates across port 3389. If there is a firewall anywhere between you and the server that’s having the problem, that doesn’t have this port open then you are out of luck. The Web interface for the Terminal Services also uses port 3389, but you can reconfigure it to use any port number that you want.

Setting up Web Based Remote Administration

Now that I have talked about some of the philosophies behind Web based Terminal Service access, let’s take a look at the setup process. The component that does all the work is technically known as Remote Administration through HTML (formerly known as the Terminal Services Advanced Client (TSAC) in Windows 2000 Server)

Begin by selecting the Add / Remove Programs option from the Control Panel. When the Add / Remove Programs applet starts, click the Add / Remove Windows Components button. This will cause Windows to display a list of Windows components that you can install. Select the Application Server option and click the Details button. Select the Internet Information Service (IIS) option and click Details again. Now, select the World Wide Web Service from the list and click Details one more time. At this point, select the Remote Administration (HTML) check box , as shown in Figure A, and then click OK three times, followed by Next. Windows will now install the necessary files. You may be prompted to insert your Windows installation CD, so be sure to keep it handy. When installation completes, click Finish.

Figure A: Select the Remote Administration (HTML) check box

Now that you have installed the necessary files, select the Internet Information Services (IIS) Manager command from Windows’ Administrative Tools menu. When the IIS Manager console opens, navigate through the console tree to Internet Information Services | your server | Web Sites | Administration. Now, right click on the Administration Web site and select the Properties command from the resulting shortcut menu to see the Administration site’s properties sheet. Now, select the Web Site tab and make note of the port numbers that are listed for the TCP and the SSL port. The default values for the TCP port and the SSL port are 8099 and 8098 respectively, as shown in Figure B. If you need to change the port numbers because of the way that your firewalls are set up, this is where you do it at. Now, select the Directory Security tab and click the Edit button found in the IP Address and Domain Name Restrictions section. If you want to restrict Terminal Service access by IP address, then this is where you would enter the addresses that you want to either allow or block. Click OK when you are done.

Figure B: The default values for the TCP port and the SSL port are 8099 and 8098 respectively

Now, let’s look at how to manage the server through a Web browser. Open Internet Explorer and enter HTTPS:// followed by the server’s IP address, a colon, and the port number. For example,  When you do, you will be prompted to log into the server. You must use an account with administrative credentials. After logging in, the Administration Web site will be displayed. To initiate a Terminal Service session, click on the Maintenance link found on the blue bar along the top, and then click the Remote Desktop button. Internet Explorer will install the necessary ActiveX component and the remote desktop will be displayed within a browser window, as shown in Figure C.

Figure C: Enter HTTPS:// followed by the server’s IP address, a colon, and the port number to access the Terminal Services over the Web


Setting up Web based Terminal Service access is not without risk. However, when properly secured, Web based Terminal Service access can be an extremely valuable management tool.

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