Configuring Telnet

Readers have written in to tell me that they’d really like to see more about Telnet after reading my Telnet Not Included post. Of course, there was the usual disagreement as to where I should begin the discussion, so I decided to start at the beginning. As previously mentioned, I do cover this command in my book Administering Windows Server 2008 Server Core,” but don’t cover it in “Windows Command-Line Administration Instant Reference.”


Adding the Telnet Server feature to a server will likely require a restart. Consequently, you should only take this task on when you know that you can reboot the server afterward.

Neither books tells you how to configure Telnet, which is a necessary first step because Microsoft doesn’t install this application automatically any longer due to some serious security considerations. The purpose of this post then is to help you configure a Telnet setup that consists of a server (WinServer for the purpose of these posts) and a client (Main). You’ll need to substitute the names of your systems when working through the commands on your system.


It’s important to note that you can perform this task on a single machine by configuring both client and server.

WinServer is a Windows 2008 R2 Server. If you have some other version of Windows, the instructions I’m providing here might not work precisely.


  1. Choose Start > Control Panel. You’ll see the Control Panel window shown here.
  2. Click Turn Windows Features On or Off. You’ll see the Server Manager window.
  3. Choose the Features folder in the left pane. You’ll see a list of installed features like the ones shown here.
  4. Click Add Features. You’ll see the Add Features Wizard.
  5. Check the Telnet Server entry as shown here.
  6. Click Next. You’ll see a message about the server needing to be restarted after you complete the installation.
  7. Click Install. Windows installs the Telnet Server feature.
  8. At some point, you’ll see an Installation Succeeded message. Click Close to close the Add Features Wizard.
  9. If necessary, reboot your system (Windows will tell you when it’s necessary to reboot). Unfortunately, your Telnet installation isn’t active yet.
  10. Open the Services console found in the Administrative Tools folder of the Control Panel (depending on how your configure your server, you might actually find this folder right on the Start menumy recommended placement for such an important feature).
  11. Locate the Telnet entry. You’ll notice that the service is not only stopped, but it’s also disabled as shown here.
  12. Double click the Telnet entry. You see a Telnet Properties dialog box like the one shown here.
  13. Choose Automatic (Delayed Start) in the Startup Type field and click Apply. Using a delayed start seems to ensure fewer problems when working with Telnet.
  14. Click Start. Telnet should now be accessible on the system.

You can also configure the Telnet server from the command line. To set the server startup configuration type, SC Config TlntSvr Start= Delayed-Auto and press Enter. To start the server, type SC Start TlntSvr and press Enter.

Once you have Telnet installed on the server, you also need to install it on your workstation. The following steps get you started.


  1. Choose Start > Control Panel. You’ll see the Control Panel window.
  2. Click Programs. You’ll see the list of Programs options.
  3. Click Turn Windows Features On or Off. You’ll see the Windows Features dialog box.
  4. Check the Telnet Client option and click OK. Windows will install the Telnet Client.

Of course, you don’t know whether your setup will even work. So, it’s time to check your setup.


  1. Choose Start > All Programs > Accessories to display the Command Prompt link.
  2. Right click Command Prompt and choose Run As Administrator from the context menu. You’ll see a User Account Control dialog box where you click Yes. At this point, you’ll have an administrator level command prompt to use.
  3. Type Telnet WinServer (or whatever the name of your server is) and press Enter. You’ll see a message warning you about sending your password to the server. The password is sent in the clear and this is extremely dangerous from a security perspective.
  4. Type Y and press Enter. Telnet will create a command prompt session on the server for you.
  5. Type Echo %ComputerName% and press Enter. You’ll see that the name of the system matches your server, so you really do have a connection to it.
  6. Type Exit and press Enter. Telnet ends the session with the server.
  7. Type Echo %ComputerName% and press Enter. The output now corresponds to your local workstation.

At this point, you have a Telnet configuration to use for future posts. Of course, you can start experimenting with it now. Any command you can normally type at the command prompt, you can likely type at the Telnet prompt as well (as long as there are no graphics involved with executing the command). Now I need to know what sorts of topics you’d like me to cover. Send me e-mail at with your requests.


An Update About Mono

I’m not one to get stuck on a particular form of a technologyit’s best to use the solution that works, rather than make a favored solution try to fit. Many .NET developers miss opportunities to move their solutions to other platforms or use them in places that normally don’t work well with the .NET Framework by leaving out Mono, the .NET Framework alternative. Most people associate Mono with the Macintosh or Linux, but there is also a Windows form of Mono. When Windows Server 2008 Server Core came out without the .NET Framework, I immediately wrote an article about it entitled, “Mixing Server Core with .NET Applications.” In fact, I’ve promoted Mono to frustrated administrators in my book, “Administering Windows Server 2008 Server Core.” Before Microsoft finally came out with a .NET Framework solution, you could use Mono to do things like run ASP.NET applications on Windows Server 2008 Server Core and my book told you how to do it in Chapter 24.

So, I was more than a little disturbed when I heard that the Mono crew had been laid off by Novell. Fortunately, I discovered later that the layoffs are just a prelude to having Mono supported by a new company named Xamarin. To read more about this company, check out Miguel de Icaza’s blog entry, “Announcing Xamarin.” Not only will the new company continue supporting the open source versions of both Mono and Moonlight (the Silverlight alternative), but it’ll create new commercial products for both Android and iOS. In short, this development is actually good because the new company will focus on this incredibly useful technology.

My main concern for the new company is that they won’t have the funding to do everything they envision doing, but that remains to be seen. Reading Mary Jo Foley’s article gives me hope that they’ll succeed. What are your thoughts about Mono? Is it a technology that you’ve used or at least are willing to try? Let me know at


Telnet Not Included

Every book I’ve written has required some hard decisions. Believe me, I think about every omission and addition at length, and then I think about them again. In many cases, I’ll ask my editors, especially my technical editor about it. In some cases, the beta readers for my book will get an e-mail about the topic as well. I made these sorts of decisions when writing Windows Command-Line Administration Instant Reference as well. So it was, after trying to wring everything I could out of every page in the book, I was faced with the unpleasant decision of having to leave Telnet out. It wasn’t an easy decision because I had included it in past tomes about the command line, such as “Administering Windows Server 2008 Server Core,” (see page 440 of that book) which also contains a wealth of other commands.

Readers have asked about the Telnet omission. I’ve been surprised to find that quite a number of people still use this utility and would have liked a more comprehensive discussion of it in my current book. There were a number of reasons for the omission. The most important at the time is that Telnet isn’t enabled by default anymore on Windows. You must install it as a separate item. In fact, you must also install the client on newer systems as shown here for Windows 7.


So, why is everyone apparently making it difficult to use Telnet? Well, it turns out that Telnet has been implicated in more than a few security problems. Telnet was designed for a time when you could trust a connection. It doesn’t provide modern security features, such as encryption for the username and passwordit passes this information in the clear so anyone can grab it. In fact, a simple check on Microsoft’s Knowledge Base shows 1,430 hits for Telnet Security Issues (as of this writing). There are many non-Microsoft sites, such as this James Stephens blog entry, that detail the problems with Telnet as well. With pages at a premium, I decided the security issues surrounding Telnet were a good reason not to include it.

I’ve written a number of command line reference books. Each with a different audience in mind. In Windows Command-Line Administration Instant Reference I chose to provide support for administrators who need quick reference to actual commands, rather than simply a command reference. In addition, the page count of this book is smaller and the book itself is a smaller size to make it easy to carry around. The addition of examples and the reduction in size meant that I had to choose which commands to cover quite carefully. As described in another recent post, Techniques for Choosing a Technical Book, it’s important that the reader choose the book that meets their needs. In some cases, readers will be better served by the more complete list of commands provided by Administering Windows Server 2008 Server Core, which is an actual reference book.

Of course, I’m always looking for ways to improve my books to make the next edition better suited to meet your needs. If I receive enough e-mail about Telnet, I may very well included it in the next edition of Windows Command-Line Administration Instant Reference. So please keep those e-mails coming! If you’d really like to see Telnet included in my next book, contact me about it at

So, here’s the short story about Telnet. As with most command line utilities, you can obtain general help by typing Telnet /? and pressing Enter. You’ll see the help screen shown here:


Notice that I’m using an Administrator command prompt. You absolutely have to elevate privileges to use Telnet successfully in Windows 7. In addition, you’ll need to open a hole in your firewall for port 23 (unless the Telnet server you want to contact is at a different porta minimal, but helpful security precaution).

In order to connect to a server, you type Telnet <ServerName>, where ServerName is the name of the server you want to contact. For example, if you want to contact a server named WinServer, you type Telnet WinServer and press Enter. Once you enter Telnet, type ? and press Enter to get help for that session.

It’s important to note that Microsoft provides some Telnet-related commands that you should know about if you really need to use Telnet for administration tasks. For example, the Telnet Server is TlntSvr.exe and you can use the TlntAdmn utility to perform administration tasks. Let me know if you’d like some additional posts on this topic and I’ll be all too happy to pursue it further.