Windows Command-Line Administration Instant Reference – Page 4

Windows XP and Advanced Command Line Utilities

Both Windows Command-Line Administration Instant Reference and Administering Windows Server 2008 Server Core contain a number of advanced commands, such as SetX, that don’t come with the operating system. A number of readers have written to ask about these commands and where they can get them. Fortunately, Microsoft makes it easy to get what you need by downloading and installing the Windows XP Service Pack 2 Support Tools.

The Support Tools site contains a list of the commands and utilities you get. Included in this list are two important MMC console configuration files (ADSIEdit.msc and SIDWalk.msc) that make management tasks considerably easier. There is an executable form of ADSIEdit, but Support Tools doesn’t include it and you can’t use ADSIEdit as a command line tool anyway. The SIDWalk utility comes in executable (.exe) form as well so that you can use it in batch files.

In order to install the Support Tools, you must provide 5 MB hard drive space. Of course, coming up with that small amount of space isn’t the problem it once was. You must also have Windows XP Service Pack 2 (or higher) installed.

Something that Microsoft doesn’t emphasize is that these tools don’t work with the 64-bit version of Windows XP. Unfortunately, I haven’t found a workaround for the problem. Utilities created for newer 64-bit versions of Windows, such as Windows 7, don’t appear to work with Windows XP. If someone has a solution to this problem, please let me know.

After you download Support Tools, you may have to add a new path to your Windows setup. You perform this task using the Environment Variables dialog box. Simply open the System Properties applet, select the Advanced tab, and click Environment Variables to access it. Make sure you add the path to your installation to the existing Path and don’t overwrite the existing path with the new information. (Highlight the Path entry in the System Variables list and click Edit to display the Edit System Variable dialog box.) In most cases, the Support Tools install to the %Program Files%\Support Tools folder, which means you’d type ;%Program Files%\Support Tools at the end of the existing Path environment variable.

I’ll provide updates to this post as needed. If you have any questions, please contact me at [email protected].

Understanding Line-, Token-, and String-Based Command Line Utilities

My books, Windows Command-Line Administration Instant Reference and Administering Windows Server 2008 Server Core, both contain batch file sections that answer basic needs, but sometimes you need more than basic information to perform a task. A reader asked me how to perform a task using the FindStr utility the other day based on my Regular Expressions with FindStr post. The problem is that FindStr is a line-based utility, and the reader was trying to obtain a token-based result. Using FindStr alone won’t solve the problem. Here is the original reader comment:

If I have lines like below in a file called Sum.txt :

Total001 abcdefg
Total002 hijklmn
Total099 opqrstuv

and I use a regular expression to get all the results like “findstr Total[000-099] Sum.txt” the result printed is :

Total001 abcdefg
Total002 hijklmn
Total099 opqrstuv

But I want it to print only the matches to the regular expression like

Total001
Total002
Total099

How can this be done?

And my response:

The FindStr
utility is line oriented, which means you obtain an entire line as
output, not individual tokens. In order to accomplish what you want to
do, you need to create a For loop. Using a For
loop would allow you to process the individual tokens in the line. The
following command will do what I think you want to accomplish:

For /F “UseBackQ” %1 In (`FindStr Total[000-099] Sum.txt`) Do @Echo %1

There are two important things to notice here. First, you must provide the “UseBackQ”
option or the command won’t work. The command itself must appear in
back-quotes—not regular quotes. The back-quote normally appears above
the Tab button and to the left of the 1 on a keyboard. It usually
appears with the tilde (~) character.

Using For makes it possible to create a token-based output from the line-based FindStr output. The default For setting relies on the space and tab characters as delimiters, but you can use the Delimiters= option to change the default behavior. However, sometimes a token-based result isn’t enough. You may not want an entire word (or whatever element the delimiters define). In this case, you need a string-based output.

One of the undocumented features of the command line is to create substrings from variables. For example, let’s say you define the following variable:

Set MyVariable=Hello World

Now, you want to obtain just a piece of that variable to use somewhere in your batch file. To obtain the substring, you use the tilde (~) operator. This operator uses a 0-based offset. So, let’s say you issue the following command:

Echo %MyVariable:~3%

The output of this command is: lo World. The output begins with the forth character, which is an l and displays the remainder of the string. However, let’s say you don’t need the rest of the string. Well, in this case, you can add a second number to define the characters you do need. If you issue this command:

Echo %MyVariable:~3,6%

the output is: lo Wor. The output begins with the fourth character and proceeds to the ninth character. The output contains the six characters you requested. In short, it’s possible to perform some fancy string manipulation in batch files as long as you keep the short of output you need in mind. Let me know how you use batch files to perform various sorts of string manipulation at [email protected].

Interacting with the Task Scheduler Service

The Task Scheduler service has become an essential part of Windows. With that in mind, Microsoft has made a change in the way this service works. You can no longer stop it and the service automatically starts when you start Windows. The idea is to ensure that the service is available to meet Windows needs. The change quietly occurred during a Vista update and is automatically part of Windows 7. Consequently, when you try to interact with the service, you get an error message of [SC] OpenService FAILED 5: Access is denied. To see this for yourself, try typing SC Config Schedule Start= Demand and pressing Enter on an update Vista or any Windows 7 system.

The reason I mention this particular issue is that on page 43 of Windows Command-Line Administration Instant Reference, you see instructions for interacting with the Task Scheduler service. You can still query the service and perform some other tasks with it, but you can’t stop it or configure the method used to start it. When you look at this service using the Services console of the Administrative Tools folder, you see that you can’t even change how the service starts as shown here (everything is grayed out).

There are a number of other services that fall into this same category. You can’t stop, start, or reconfigure them. Here is a list of the most common services that you can’t control using the SC utility (you can still query all of them):

DCOM Server Process Launcher
Group Policy Client
Plug and Play
Remote Procedure Call (RPC)
RPC Endpoint Mapper

Microsoft hasn’t documented the reason why you can’t configure any of these services. However, the reason that Microsoft has made it impossible to change the Task Scheduler service is that Windows 7 uses it extensively. For example, a number of applications rely on the Task Scheduler:

System Restore
Reliability History
Windows Update
Other Program Updates

In addition, Windows 7 uses Task Scheduler to perform a number of checks. These checks affect system reliability and stability:

TCP/IP Conflicts
Disk Diagnosis
Network Information
System Sound Service
Power Controls
WinSAT

Even so, you may find that you need to stop the service for some reason. The common technique that you’ll find for overcoming this problem is to perform the task from the registry. Open RegEdit and locate the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Schedule key. The Start value controls how the Task Scheduler starts. Double click this value and change the entry to 4 as shown here to disable the service, or 3 to set it to manual.

Reboot the system. You still won’t be able to make any changes using the SC utility or the GUI, but the status of the service will change to either disabled or manual as you requested. When the service is in manual mode, you can start it manually. Change the Start value back to 2 to re-enable the service. The problem with changing these services is that you don’t know how the change will affect system stability. This is a change at your own risk scenario. Please let me know if you have any questions at [email protected].

Obtaining Command Line Help

Both Administering Windows Server 2008 Server Core and it’s more diminutive counterpart, Windows Command-Line Administration Instant Reference, are reference manuals that tell how to use the command line to perform specific tasks. The first book is more complete, in that it contains many uncommon commands and utilities. The second book is designed to provide more hands-on help by supplying a significant number of actual usage examples. In both cases, you get a significant amount of help about the commands. As long as you have one of these two books by your side, you’re in great shape for knowing how to use the commands at the command line. Unfortunately, the reality is that most of us don’t stuff a library full of books in our back pocket. Even with an e-Reader, such as the Kindle, you can be sure of having the device available every time you need it. So, how do you get at least some quick help when there aren’t any resources available?

The first thing to remember is that you can get at least some useful information for any command or utility by using the /? or -? command line switches (some commands and utilities are peculiar in that they require either the /? or the -? command line switch, while many will allow you to use either). For example, when you want to discover how to use the Dir command, you type Dir /? and press Enter. Here’s typical output when using the /? command line switch.

This help screen is also typical in showing what you get. Help normally includes a short description of the command, the command line syntax, and a short description of each of the command line switches. You may also see usage examples for more complex commands. In rare cases, the help screen will provide an URL for additional help.

Some commands and utilities are complex enough that they require several help screens. For example, if you type WMIC /? and press Enter, you’ll see a list of help topics, not help of the sort provided for the Dir command. Let’s say you want to know more about the CPU topic. So, now you type WMIC CPU /? and press Enter. The help looks a little more normal now, but still isn’t very complete because you need to choose a subcommand. Perhaps you want just a list of CPUs on a system, so you request information about the List subcommand by typing WMIC CPU List /? and pressing Enter. Wow, now you see a number of listing formats. This time you add a listing format by typing WMIC CPU List Brief /? and pressing Enter. It turns out that you can also discover information about command line switches used with the Brief format. The final level in this case is to type WMIC CPU List Brief /Translate /? and press Enter. The WMIC utility is unique in providing so many levels of help, but other complex commands and utilities, such as Net, do provide multilevel help.

No matter how many help screens you see, sometimes it isn’t enough to give you the help you need. That’s when you need to find your copy of my book to get additional information. Of course, a single book can do only so much—some complex commands and utilities may require still more information. Technet is a good place to start. For example, you can find an excellent article on WMIC at http://technet.microsoft.com/library/bb742610.aspx. Knowledge base articles also provide useful information, especially when it comes to issues that Microsoft has solved for a given command or utility. For example, the Knowledge Base contains an article entitled, “How to find computer serial number” that relies on WMIC. Finally, make sure you look at third party articles, such as the one entitled, “WMIC: the best command line tool you’ve never used.”

Many people complain about not being able to remember all of the commands and utilities, and this is a problem. After you use a command or utility often enough, you tend to remember it, but the memorization process can take time. Unfortunately, there isn’t any single quick method of finding every command or utility on a system. However, you should start by typing Help | More and pressing Enter. (Using the More command lets you see the information that a utility has to provide one screen at a time, rather than seeing the information scroll right past.) You’ll get a list of common commands like this one.

Not all of the commands appear on this list and none of the utilities do. Another way to obtain the information you need is to type Dir *.COM and press Enter in the \Windows\system32 directory. (You can type CD \Windows\System32 and press Enter to get to the appropriate directory.) Every directory entry you see is very likely a utility. However, many utilities are in .EXE form, so you also need to type Dir *.EXE | More and press Enter. You can eliminate files that contain more than eight letters in the filename from the list in most cases because command line utilities usually rely on the old 8.3 naming convention. Check filenames that look like they could be what you want by typing Filename /? and pressing Enter (where Filename is the name of the file you want to test). Useful command line utilities will generally display a help screen.

Now that you have a better idea of how to get command line help when you need it and where to obtain a list of useful commands and utilities, you should take some time to try it out for yourself. What techniques do you use to obtain the additional information you need at the command line? Let me know at [email protected].

Understanding the Connection Between Application Output and ErrorLevel

Many readers have a disconnect between application output and the ErrorLevel variable found in batch files. I’ve received more than a few e-mails where readers don’t quite understand the whole concept behind the ErrorLevel variable. They think it actually signifies some sort of mystical operating system derived error, when it isn’t anything of the sort.

A large part of the problem is that those readers who commonly work with batch files aren’t developers and many developers don’t work with batch files. In fact, even though many administrators are moving back to command line utilities because working with the GUI is time consuming and inefficient, many developers have decided to eschew the console application in favor of GUIs with fancier user interfaces.

Another problem is that ErrorLevel is inappropriately named. It should really be named ApplicationOutput. I’m sure that at one time the intention truly was to convey some sort of error information, but even Microsoft uses ErrorLevel for other purposes.

Let’s take a practical look at the whole concept of ErrorLevel beginning with a simple C# application to generate the codes. When working with C#, you’ll find that the output is now called an ExitCode as shown here.

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

namespace GenerateOutput

{

class ExitCode

{

static void Main(string[] args)

{

// Create a variable to hold the exit

// value.

Int32 Value;

// Make sure there is a variable provided as input.

if (args.Count() > 0)

{

// Determine whether the input is actually a number.

if (Int32.TryParse(args[0], out Value))

// If it is, then exit using that number.

Environment.Exit(Value);

else

// Otherwise, exit with an error value of -2.

Environment.Exit(-2);

}

else

// Exit with an error value of -1

Environment.Exit(-1);

}

The only purpose of this application is to generate exit codes given certain circumstances. The first check determines whether the user has supplied any sort of input at all. If not, if the user simply types GenerateOutput without any arguments at all, then the application exits with a value of -1 to indicate an error. Likewise, if the user types something other than a number, such as GenerateOutput Hello, the application exits with a value of -2 to indicate a different sort of error. Only when the user supplies a number does the application exit with a numeric value.

The batch file used to test this application is equally simple. All it does is call GenerateOutput with the value (if any) that the user provides to the batch file, TestOutput.bat. Here’s the batch file code.

@Echo Off

REM Run the application.

GenerateOutput %1

REM Most application output are status indicators.

If ERRORLEVEL 2 GOTO HighOutput

REM You can perform specific actions for a specific status.

If ERRORLEVEL 1 GOTO ValueOne

REM Applications can also provide a success indicator.

If ERRORLEVEL 0 GOTO Success

REM Errors are normally negative numbers, but can be anything.

If ERRORLEVEL -1 GOTO Error1

If ERRORLEVEL -2 GOTO Error2

:HighOutput

ECHO The value you provided is higher than 1.

GOTO End

:ValueOne

ECHO You provided an input of precisely 1.

GOTO End

:Success

ECHO An output value of 0 indicates success!

GOTO End

REM Here is the beginning of the various messages.

:Error1

ECHO You must supply a number as an argument!

GOTO End

:Error2

ECHO You must supply a number and not text or special characters!

GOTO End

REM Here is the ending point.

:End

As you can see, the tests check for errors, success messages, and non-error application output. Any combination of console application and batch file can do the same thing provided the developer and administrator get together to work out the details or the developer at least documents the exit codes.

The process is the same each time. Test for an ErrorLevel value, then go to the label specified, execute the directions, and then go to the end of the batch file. The ErrorLevel values must appear in order from greatest to least in order to work correctly. Here is some test output from this test application and batch file pair.

The point of this exercise is to ensure that developer and administrator alike realize the importance of the exit code (ErrorLevel). The application should use it to provide some sort of status information that the administrator can then use to track how well the application works in an automated setting. Let me know if you have any questions at [email protected].

Automating Your Configuration with a Daily Batch

Batch files are still an important part of your system, especially if you find that you need to perform certain configuration tasks every day. Both Administering Windows Server 2008 Server Core and Windows Command-Line Administration Instant Reference discuss batch files, but this post is about a practical example of a batch file in daily use.

My system has a daily batch file. It runs every morning when I start the system up. (To save electricity, I do turn off my system every night and find that things also run better because I do.) The main reason for using a daily batch file is to configure my system so I don’t end up performing the same repetitive tasks every day. I tell the computer what to do and it performs the required configuration for me. After I get my cup of coffee, my system is ready to go—fully configured for my use.

The daily batch file appears as an entry in the Startup folder on my system. Placing the file in the Startup folder means that it runs automatically, but that I can also easily disable the batch file should I wish to do so. Use these instructions to add a daily batch file to your Startup folder:

Choose Start > All Programs. You see a list of entries including Startup.
Right click Startup and choose Open from the context menu. (Unless you want everyone to use the same automatic batch file, you don’t want to choose Open All Users.) You see a copy of Windows Explorer open for the Startup folder.
Right click anywhere in the right Windows Explorer pane and choose New > Text Document from the context menu. Windows will create a new text document named New Text Document.txt—however, only the New Text Document part of the filename is highlighted.
Highlight the entire filename and type Daily Tasks.bat. Make absolutely certain that you also overwrite the .txt part of the filename—Daily Tasks.bat.txt won’t do anything for you.
Press Enter. You see a Rename dialog box that asks whether you’re sure that you want to change the extension of the file.
Click Yes. Windows renames the file.

Of course, the file is empty at this point. Right click Daily Tasks.bat and choose Edit from the context menu. Windows will open a copy of Notepad with the empty batch file loaded. At this point, you can start typing commands for Windows to execute automatically when you start up in the morning. It’s possible to execute many commands directly—especially those that are meant to execute at the command line, such as W32Tm /Resync, which forces an update of the system clock. Other commands require that you use the Start command to execute them. For example, you might want to tell Firefox to automatically open the Astronomy Picture of the Day site using this command:

Start “C:\Program Files\Mozilla Firefox\Firefox” http://antwrp.gsfc.nasa.gov/apod/

<font<> <font<>The Start command starts Firefox in this case. It passes the URL you provide to Firefox as a command line parameter. Obviously, the application must support command line parameters for this technique to work. More applications than you might think do support command line parameters (many undocumented), so a little research can provide a lot in automation.

Any command that you can execute in any other batch file is also available when you’re starting Windows. There is one special consideration. You’ll likely find that executing one command immediately after another causes timing problems when Windows is initially starting. For example, if you try to open several Web sites, you’ll find that Windows actually misses opening a few unless you provide some sort of wait period between commands. Fortunately, the Choice command fulfills this task perfectly. For example, the following command provides a 15 second delay that you can insert between commands:

@CHOICE /C:N /N /T:15 /D:N

Using this command the user won’t even be aware of the delay. The @ symbol makes the Choice command invisible. The /C command line switch provides the available choices (which consists solely of N in this case). The /N command line switch hides the list of choices from view. You create the actual timeout value using the /T command line switch, which is set for 15 seconds in this example. However, the /D command line switch actuates the delay by automatically choosing N after the 15 seconds. In short, this entire command line is a wait statement.

If you want your batch to run more or less invisibly, make sure you start it with an @Echo Off command. Otherwise, every command appears in the window. It’s helpful to check for errors when you first put the batch file together and when you make changes. Adding an @Pause at the end of the batch file keeps the command window visible so you can check for errors.

After you finish the batch file, you can execute it as you would any other batch file. The only difference in this situation is that this batch file executes automatically each day because it resides in the Startup folder. When you need to make changes to this file you can choose Start > All Programs > Startup, then right click Daily Tasks.bat, and choose Edit from the context menu. The file will open in Notepad for you.

This is one of the more interesting and useful ways to employ batch files. What are your favorite batch processing techniques? Let me know at [email protected].

A Visual Studio Quick Guide to Accessibility (Part 1)

One of the most important accessibility aids that also applies to common users is the keyboard accelerator (or keyboard shortcut). In fact, this issue figures prominently in both C# Design and Development and Accessibility for Everybody: Understanding the Section 508 Accessibility Requirements. Just why Microsoft decided to turn this feature off in Windows 7 is a complete mystery to me. All of the pertinent examples in Professional Windows 7 Development Guide include keyboard accelerators, but you can’t see them. I’ve received a number of queries about this problem and decided that this two-part post on accessibility for Visual Studio developers is really necessary.

First, let’s discuss the keyboard accelerator from a programming perspective. A keyboard accelerator is the underline you see on a button, label, menu, or other control. You press Alt+Letter to perform the equivalent of a click or selection with the associated control. For example, most people know that you press Alt+F to access the File menu in an application that has keyboard accelerators properly implemented.

To create a keyboard accelerator, the developer precedes the letter or number with an ampersand (the & character). For example, to make the File menu respond to Alt+F, the developer would type &File in the development environment. I’ve always strongly encouraged the use of keyboard accelerators as a must have for any application because many keyboardists are seriously hindered by an application that lacks them. In fact, you’ll find the keyboard accelerators used in the vast majority of my books, even for examples that aren’t related to programming in any way.

Second, some developers who feel as I do about keyboard accelerators are upset that adding them to applications no longer works (apparently). Windows 7 hides the keyboard accelerators for some odd reason known only to Microsoft. The Ribbon interface provides an equivalent when the developer provides it, but we’re talking about all of the applications (the vast majority) that don’t use the Ribbon interface. It turns out that you must manually turn the keyboard accelerator support back on. Follow this steps to accomplish the task manually:

Open the Control Panel, followed by the Ease of Access applet. Click the Ease of Access Enter link. You’ll see the list of options shown here:
Click Make the Keyboard Easier to Use. You’ll see a list of options for making the keyboard easier to use. Near the bottom of the list you’ll see the Underline Keyboard Shortcuts and Access Keys option shown here.
Check this option and then click OK. The system will now display the underlines as before.

One of the biggest questions I had while working through this is whether there is a method for turning this feature on or off at the command line. There isn’t any WMIC command that I’ve found to make the change (nor any other command for that matter), so I’m currently trying to discover the associated registry keys. I’ve found one so far. The On value in the HKEY_CURRENT_USER\Control Panel\Accessibility\Keyboard Preference key must be changed to 1. However, that value alone doesn’t make the change work, so there are more keys and values to find. If anyone has some clues to provide me about this particular need, please let me know at [email protected]. In the meantime, I’ll continue looking for the elusive registry updates required to automate this change.

Interacting with the Remote System Using Telnet

Today marks the last post in my Telnet series unless someone writes with additional ideas on issues they’d like me to cover. So far, I haven’t received any requests for Telnet scripting topics, so I’ve decided that perhaps there isn’t a lot of interest in this topic. I discussed basic Telnet connectivity in the Using Telnet to Perform Tasks post. The last post, entitled “Sniffing Telnet Using Wireshark,” covered Telnet security issues. Today’s topic is a natural extension of the topics discussed so far—now that you have an interactive session with a remote system (router, server, or workstation, it doesn’t matter), what can you do with it?

My book, “Administering Windows Server 2008 Server Core,” provides a few ideas on the topic, but not very many. I’m thinking now that perhaps I should have discussed this topic in “Windows Command-Line Administration Instant Reference,” but then there is always the question of the cost to other topics and I had no idea when I wrote that book that Telnet was still so popular with some administrators. The short answer is that you have a fully functional command prompt.

The problem is that you’re working with a remote command prompt, not the local command prompt. So, the command prompt you’re accessing is the one on the remote system, with all its attendant resources and limitations. As a consequence, unless you’re working with that system every day, you’ll want to type Ver and press Enter to see which version of the command prompt you’re using. It seems like a simple thing to do, but some administrators don’t and later discover that problems at the command line had nothing to do with the session, but the version of the command line. If you’re working with Windows, you can find a complete list of Windows OS Version numbers on MSDN.

Knowing the version number and the associated operating system name lets you look for commands for that OS in either of my books or you can look them up online. For example, you can use the search phrase, “Windows XP Command Line” on Google (or any other search service) to obtain quick access to sites such as Technet where you can find a listing of associated commands from A to Z. Obviously, these sites will only tell you which commands are available, not how to use them, but knowing what’s available does help.

Another problem that many administrators encounter is that they don’t consider the environment. Again, the environment focuses on the remote system, not your local machine. So, that favorite path might not be part of the Path environment variable and typing a much beloved command won’t work at all. Consequently, it pays to type Set | More and press Enter so that you can look through the environment variables to ensure everything you need is available. This command also provides some essential cues about the remote system configuration. For example, if the Set command reveals a ProgramFiles(x86) environment variable, then you know you’re working with a 64-bit system and some older commands may not work as anticipated. Use the Set command to add or modify any environment variables required to get your work done.

At this point, you know which commands you can execute and you know that the environment is configured for use. What you don’t know is whether you have the rights required to accomplish the task. You can use commands such as ICACLS to verify your rights or you can simply try the command to see whether it completes successfully. The important thing to keep in mind is that newer versions of Windows employ the UAC, even at the command line, so you might find your efforts thwarted.

Even when everything is working properly and you have all of the required rights, you should avoid using certain commands in a remote session. For example, you definitely don’t want to start another copy of Telnet from the remote session (assuming the remote session will even allow it). Using the WinRS command probably won’t work well either. However, Terminal Server commands such as QWinSta appear to work just fine. Let me know your thoughts about Telnet at [email protected].

Sniffing Telnet Using Wireshark

In my previous post about Telnet entitled, “Using Telnet to Perform Tasks” you discovered how to use Telnet to work interactively. Now you have enough information to view some of the security issues with Telnet. It’s incredibly easy for someone to monitor your Telnet session. The only protection you have is firewalls and other security you might have in place—Telnet is completely open and offers nothing in the way of security. Lack of security is one of the reasons I didn’t cover this utility in the “Windows Command-Line Administration Instant Reference.” (Telnet is covered from a command line perspective in “Administering Windows Server 2008 Server Core.”) However, the lack of security isn’t a problem in some situations and many administrators prefer to use Telnet to manage some network hardware such as switches and routers. Consequently, the main emphasis of this post is building an awareness of the security issues behind using Telnet so that you can make a good decision about using it to meet your needs.

Before you can see the security issues for yourself, you need to download a utility to sniff packets on your network. This post will rely on a free utility named Wireshark because it does the job admirably and is supported on a number of platforms. Because I’m using the 64-bit version of Windows 7, I downloaded the 64-bit Windows installer for the 1.4.7 version of Wireshark. To make things simple, I performed a full install. Part of the Wireshark setup will also install WinPcap, so you don’t need to install this product separately. If you’re using some other version or configuration of Wireshark, your screen may not look precisely like mine.

Using a sniffer is somewhat dangerous and you need administrator privileges to do it. This post isn’t designed to make you an expert in protocol sniffing. In fact, this post is exceptionally simple and is designed only to make you aware of deficiencies in Telnet security. The nefarious individual who gains access to your network to sniff about will have significantly more skills and be able to learn considerably more than you’ll learn using the simple directions in this post.

After you complete the installation, you’ll be able to start Wireshark. Choose Start > All Programs > Wireshark and you’ll see the initial Wireshark display shown here.

Wireshark isn’t configured to work with Telnet at the outset, so you need to tell it what to sniff. Click Capture Options and you’ll see what looks like an incredibly complex Capture Options dialog box like the one shown here.

We’re not going to worry about the vast majority of these options. In fact, you only need to set two options to sniff out Telnet packets. Look first at the Interface field. Make sure it’s set to Local. Select your network adapter from the drop down list box. The network adapter will normally have a human readable name, not something odd as shown in the screenshot.

Next you need to tell Wireshark what to sniff on the interface you’ve selected. Click Capture Filter. Type Telnet in the Filter Name field and port 23 in the Filter String field. Click New. Your dialog box should look like the one shown here.

Click OK. You’ll see the filter criterion entered in the Capture Filter field. More importantly, Wireshark is now configured to offer a Telnet filter anytime you need one. Click Start. The Wireshark display will change, but you won’t see anything on it—the display will be blank.

Open a command prompt and start a copy of Telnet in interactive mode. Make sure you open a command prompt with administrator privileges. The act of starting Telnet won’t create any packets as you can see in Wireshark. In fact, type ? and press Enter. You’ll see that Telnet is still perfectly safe—it isn’t generating any packets.

Use the Open command to open a connection to your server. Simply typing O ServerName and pressing Enter generates packets. You can see them in Wireshark like this:

Notice that some of these entries are labeled Telnet Data. In addition, the Source and Destination columns tell you which direction the information is flowing (the client is 192.168.137.131 in this case). Click on the first of these entries and you’ll see that the middle panel contains some information about the Telnet Data. Open the Telnet entry and you’ll see some interesting information as shown in the figure. For example, the packet information tells the viewer that Telnet is set to use the authentication option.

Go back to the command prompt now. Type y and press Enter to send your password information to the server. Of course, one of the big questions you probably have is whether Telnet is exposing your username and password. Near the end of the packets, you’ll find one that contains an Suboption Begin: Authentication Option entry like the one shown here.

In this case, the option entry tells the server that the client won’t forward the authentication credentials. The option works because I’m already signed onto the server and the server already has my credentials. This is one of the items you’ll want to check for your own Telnet setup, however.

Unfortunately, this session isn’t safe by a long shot. Type just a single letter, a D, at the command prompt. You’ll find that typing this single letter generates a packet that you can see with Wireshark like the one shown here.

In fact, you’ll find that every action on your part creates more packets—each of which is easily sniffed by anyone with Wireshark or any other application of the sort. Finish the command by typing ir and pressing Enter. You’ll see the expected response at the command line.

At this point, you can also see the response from the server in Wireshark. The text isn’t as readable because it contains all of the control characters normally used to format the text. However, here’s an example of the response as it appears on my system.

Look at this response carefully and you’ll see that anyone can learn precisely what you’re doing. If you have to enter passwords to perform a particular task, the viewer will get them too. Telnet isn’t a secure method to manage anything—you need to provide a secure environment in which Telnet can run. This post only touches on the tip of the iceberg, of course. Let me know if you have any questions about it at [email protected].

Using Telnet to Perform Tasks

The previous post in this series, Configuring Telnet, helped you get Telnet set up on a system. Now that you have Telnet installed, you can use all of the command line and interactive features described in “Administering Windows Server 2008 Server Core“ to access it. For example, you can simply type Telnet <Name of Server> and press Enter to start a session with that server. Because of the way Telnet works and the commands that you’ll issue, it’s always a good idea to use an Administrator command line when working in either Vista or Windows 7. To open such a command line, you choose Start > All Programs > Accessories, right click the Command Prompt entry, and choose Run As Administrator from the context menu. You may have to supply a password to gain administrator access.

When you plan to work with Telnet for an extended period, you might find the interactive environment more suited to your needs. To enter the interactive terminal, you simply type Telnet and press Enter. This action places you at the Microsoft Telnet prompt, but doesn’t open a connection for you. Type ? and press Enter to see a list of available commands as shown here.

One of the advantages of using the interactive prompt is that you’ll find it easier to configure Telnet options. To see these options, type Set ? and press Enter. For example, if you want to make your Telnet session a little more secure (and the emphasis is on little), type Set NTLM and press Enter. Some settings are a toggle. For example, if you want to remove NTLM authentication, you type Unset NTLM and press Enter. Type Unset ? and press Enter to see a list of toggled settings. Here is a list of the settings available when using the Windows 7 version of Telnet (your version of Telnet might vary).

The ability to set or reset settings is nice, but it would also be nice to know how Telnet is configured. To obtain this information, you type D (for display) and press Enter. You’ll see a list of configured settings. The default settings depend on your version of Windows and how you configured Telnet in the past. If you don’t see a particular setting, it means that the setting either isn’t configured or is toggled off (unset).

Simply configuring a setting doesn’t guarantee that Telnet will use it. The server determines whether a particular setting is valid. For example, you can request NTLM authentication, but the authentication won’t occur if the server doesn’t support it. Likewise, your choice of terminal is sent to the server, but the server ultimately chooses the terminal type, which is going to be ANSI in most cases.

To create a connection in interactive mode, you type O <Name of Server> and press Enter. You may see a warning message about sending your password in the clear. Type Y and press Enter. At this point, you’ll see the standard Telnet prompt at the server. To regain access to the client side prompt, you press a control key combination. The default is Ctrl+]. This will take you back to the client Telnet prompt where you can enter additional commands. When you want to go back to the server side, simply press Enter twice.

To check your connection, type St and press Enter. You can also ask the server questions, such as “are you there” using the Sen command. To see all of the send options, type Sen ? and press Enter. The help list shows those commands that Telnet definitely supports. However, the Knowledge Base article entitled, “The TELNET Protocol” seems to tell a different story (I’ll check out these additional commands for a future post). For the sake of doing something interesting, try typing Sen AYT (for are you there) and press Enter. Here is typical output from this command.

Now that you’ve asked for information, press Enter twice to see the server’s response. In most cases, you’ll see YES as shown here.

You have several ways to close a connection. However, for this session, press Ctrl+] to return to the Telnet client session. Type C and press Enter. The connection is now closed. To verify this fact, type St and press Enter. Type Q and press Enter to leave the Telnet interactive environment. Now, here’s the interesting part of all this. You can also script this sort of behavior to make many tasks automatic. A future post will also pursue this topic in more detail. For now, let me know if you have any questions about the basic interactive session at [email protected].

S	M	T	W	T	F	S
	1	2	3	4	5	6
7	8	9	10	11	12	13
14	15	16	17	18	19	20
21	22	23	24	25	26	27
28	29	30