Windows Command-Line Administration Instant Reference – Page 5

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.

Choose Start > Control Panel. You’ll see the Control Panel window shown here.
Click Turn Windows Features On or Off. You’ll see the Server Manager window.
Choose the Features folder in the left pane. You’ll see a list of installed features like the ones shown here.
Click Add Features. You’ll see the Add Features Wizard.
Check the Telnet Server entry as shown here.
Click Next. You’ll see a message about the server needing to be restarted after you complete the installation.
Click Install. Windows installs the Telnet Server feature.
At some point, you’ll see an Installation Succeeded message. Click Close to close the Add Features Wizard.
If necessary, reboot your system (Windows will tell you when it’s necessary to reboot). Unfortunately, your Telnet installation isn’t active yet.
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 menu—my recommended placement for such an important feature).
Locate the Telnet entry. You’ll notice that the service is not only stopped, but it’s also disabled as shown here.
Double click the Telnet entry. You see a Telnet Properties dialog box like the one shown here.
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.
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.

Choose Start > Control Panel. You’ll see the Control Panel window.
Click Programs. You’ll see the list of Programs options.
Click Turn Windows Features On or Off. You’ll see the Windows Features dialog box.
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.

Choose Start > All Programs > Accessories to display the Command Prompt link.
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.
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.
Type Y and press Enter. Telnet will create a command prompt session on the server for you.
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.
Type Exit and press Enter. Telnet ends the session with the server.
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 [email protected] with your requests.

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 password—it 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 [email protected].

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 port—a 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.

Working with Net User

The Net User command on page 142 of Windows Command-Line Administration Instant Reference seems to have generated a bit of confusion. The /Add command line switch is straightforward; /LogonPasswordChg isn’t. For one thing, the /LogonPasswordChg command line switch doesn’t appear to be documented, even in Windows 7. Here’s the help provided with Net User now:

As you can see, not even a mention for /LogonPasswordChg. Microsoft doesn’t help matters. For example, if you look at the “How to Use the Net User Command” Knowledge Base article, you won’t find any mention of this command line switch. While writing the book, I had found a tantalizing clue at Manage XP and Vista Users Using DOS Commands and decided to try it on Windows 7 as well. The command works fine when used correctly in Windows 7.

However, here is where the plot thickens. It seems that the command line switch doesn’t work in Windows XP. When you execute the command shown on page 142 you get an error message reading something like, “The option /LOGONPASSWORDCHG:YES is unknown.” Somewhere between Windows XP and Vista, Microsoft added the /LogPasswordChg command line switch to Net User and then didn’t tell anyone about it. Consequently, the command shown on page 142 won’t work under Windows XP.

There is another problem that occurs when using the /LogonPasswordChg command line switch. If the account currently has the Password Never Expires option checked as shown here:

the command appears to succeed, but doesn’t change anything. In order to make the command work properly, you must first set the password to expire using the WMIC Path Win32_UserAccount Where Name=’UserName’ Set PasswordExpires=True command. So, the sequence to set an existing account to force a password change during the next logon is like this:

When you execute these two commands, you’ll see the user account settings to change to appear like this:

which means the user must change the password during the next logon.

So, why does the command on page 142 work without this extra step? In this case you’re adding a new user and the Password Never Expires option is disabled by default. Creating the combined command works fine because there is nothing to hinder it with a new account. Please let me know if you encounter any problems with this particular command at [email protected].

Delimiters and Batch Files

The example on page 402 of Windows Command-Line Administration Instant Reference produces the correct result. You see the result of passing various bits of information between two batch files. However, as someone wrote to me recently, the output from the Batch2.BAT file isn’t the result you might expect. Instead of showing the entire %PATH% environment variable, you see just the first part of this environment variable as shown here.

The reason you only see C:\Program as the environment variable output is the fact that %PATH% contains delimiters. There are a number of characters that the command prompt uses as delimiters, separators between elements in a single string. My testing shows that the space, tab, and semi-colon are three characters that always act as delimiters within a batch file. Of course, delimiters are extremely useful when you want to use one string to hold multiple elements for processing, but they can also cause interesting results, such as in this case where only part of the %PATH% environment variable appears in the output.

Of course, you’re probably asking how to obtain the entire environment variable as output. A simple change to Batch1.BAT makes this possible as shown here.

@ECHO OFF

Call Batch2.BAT

Call Batch2.BAT Passed %1 "%PATH%"

ECHO In Batch 1

GOTO :EOF

ECHO Goodbye

Notice that %PATH% now appears within double quotes. This change tells the command processor not to process the information within the %PATH% environment variable as separate entities. With this change you see the following output.

Now you’re seeing the entire environment variable in the output. It’s important to note this difference in processing strategies when creating batch files of your own. What other batch file quirks have you encountered. Let me know at [email protected].

Deleting a Session at the Command Line

A reader of my book, Windows Command-Line Administration Instant Reference, recently wrote in to say that the Net Sessions /Delete command apparently doesn’t work, which I found interesting because I’ve tested it on a number of occasions and found it always worked for me. It turns out that we had two different scenarios in mind. Normally, you’ll use the Net Sessions /Delete command to free up resources when a remote terminal has frozen or left the session intact in some other way. For whatever reason, the remote user didn’t log out and that means all of the file locks are still in place, for one thing, and that all of the session resources are in use, for another. Using Net Sessions /Delete cleans up this mess, but only at the potential expense of data loss and all of the other things that go with terminating a session without following the usual protocol.

In this case, the reader was simply trying the command to see if it would work. However, the command didn’t appear to work become the remote terminal was still active. Since Windows XP SP1 there has been an automatic reconnection feature. You disconnect the session and Windows XP (and above) automatically reconnects it. You can read about it at http://support.microsoft.com/kb/323258.

Microsoft used to say that you had to turn this feature on manually (such as by using a policy). The fact of the matter is that the sessions automatically reconnect by default. You’ve probably seen it work already. For some reason, the network disconnects. However, after a few seconds, you magically see the network connection reappear. I know I’ve even seen it on my network. There isn’t anything magic about it—the session is being automatically reconnected in the background without any interaction from you. So…while the command does in fact work, it’s disabled by the automatic reconnection feature. Windows can reconnect faster than you can disconnect it.

Of course, this makes me wonder about other commands that apparently don’t work, but are merely thwarted by well-intentioned Windows behavior. Let me know if you see any behavior of this sort at [email protected].

Considering the Move to IPv6

I was getting my technical reading done this morning and ran across yet another article about IPv6 by Woody Leonhard entitled, “Caution: Bumps in the road to IPv6“. One of the main focuses of the article is that you should check your IPv6 compatibility using the features provided by Test Your IPv6 Connectivity. The article also assumes that you have IPv6 installed on your local system if you’re using a newer version of Windows. Of course, most people do have IPv6 functionality on their Windows 7 systems, but what if you don’t? How can you even check for IPv6 functionality?

Performing a local check is relatively easy. Open a command line, type IPConfig, and press Enter. You’ll see a listing of your IP configuration similar to the one shown here:

In this case, you can see that the connections do indeed have IPv6 connectivity. If you need additional information, you can type IPConfig /All and press Enter instead. Of course, the presence of the information doesn’t always mean that the connections are working properly. In many cases, you can fix IPv6 problems by using the IPConfig /Renew6 command. There are separate versions of the command for IPv6 and IPv4—the IPv4 version of the command is simply IPConfig /Renew, so make sure you use the correct version.

The IPConfig utility is good for quick information and fixes. If you want to perform something a little more detailed, you need the NetSH utility instead. For example, if you want to install IPv6 on a machine, you type NetSH Interface IPv6 Install and press Enter. Interestingly enough, you need to simply know about this particular command because it doesn’t appear when you type NetSH Interface IPv6 and press Enter (which shows the other available IPv6 commands) as shown here:

However, you do get a wealth of information from NetSH. Type NetSH Interface IPv6 Show and press Enter to see the entire list of Show commands listed here:

One of the least appreciated and underused NetSH commands is NetSH Interface IPv6 Dump. This command creates a batch script for you that recreates the configuration on the current machine as shown here:

So, if you type NetSH Interface IPv6 Dump > IPvConfig.BAT and press Enter, you end up with a batch file you can use to create a successful configuration on other systems. The Dump subcommand is available in a number of NetSH contexts and you should employ it freely. You can find myriad other uses for NetSH in Chapters 2 and 24 of Windows Command-Line Administration Instant Reference. The IPConfig utility appears in Chapter 9. Let me know about your unique uses for both of these utilities at [email protected].

Quotas Revisited for Windows XP

The other day I provided a post about quotas that contained a simple three step process for turning quota monitoring on and logging quota events, without actually enforcing the quota. It turns out that the process works just fine with Vista and Windows 7, but it doesn’t quite work with Windows XP. Microsoft made a fix between operating systems and didn’t mention the change to anyone. Of course, this is an old story with Microsoft. You have to watch carefully because you might miss a fix and find that your perfectly functioning batch file or script suddenly stops working.

It turns out that Windows XP does things a little differently. When you execute the FSUtil Quota Track C: command, you get the expected result; tracking is enabled. The next step is to turn on exception logging using the WMIC QuotaSetting Where Caption=”C:” Set ExceededNotification=True command, which also works as expected. However, when you execute the WMIC QuotaSetting Where Caption=”C:” Set WarningExceededNotification=True command to turn on warning logging, suddenly, the exception logging is turned off. Likewise, if you were to reverse the order of the two WMIC commands, you’d find that warning logging is turned off.

Fortunately, there is a fix to this problem and it’s a very odd fix indeed. In order to enable tracking and turn on both levels of logging, you need to follow this order in Windows XP:

FSUtil Quota Track C:
WMIC QuotaSetting Where Caption=”C:” Set ExceededNotification=True
WMIC QuotaSetting Where Caption=”C:” Set ExceededNotification=True

That’s right, you issue the exception logging command twice and you’ll find that both logging check boxes are checked. Microsoft fixed this particular error between Windows XP and Vista, but I can’t find any source that tells me about the fix. If you find one, feel free to contact me at [email protected].

FSUtil and Quotas

There is more than a little confusion about the use of FSUtil with quotas. For one thing, precisely why would someone use the FSUtil Quota Track command when it doesn’t enforce the quotas you set? I’m sure Microsoft has some scenario in mind for just tracking and not enforcing the quotas. I did talk with one of my administrator friends. She uses just the tracking option at her company. The reasoning is that she can then talk with the user when the user goes over a limit. In this particular organization, it’s bad form to limit the user’s access to the hard drive when in the midst of an important procedure (as it might have dire consequences). She says that she does see the event log entries when someone goes over their quota. So, that’s one potential scenario—you have an administrator that has to work with the users to maintain the hard drive but isn’t allowed to enforce those limits directly because doing so could impede work.

Of course, one of the problems with the tracking feature is that it doesn’t automatically set logging. In order to configure drive C on your system to track user activities and log them in the event, you must initially configure the drive using these three commands.

FSUtil Quota Track C:
WMIC QuotaSetting Where Caption=”C:” Set ExceededNotification=True
WMIC QuotaSetting Where Caption=”C:” Set WarningExceededNotification=True

The two WMIC commands set the two logging options for you. What these commands do is set the quota exceeded and quota warning flags for drive C. After you issue these three commands, the Quota Settings dialog box will look like this:

You can now add quotas using the FSUtil Quota Modify command as described in page 89 of my book, “Windows Command Line Administration: Instant Reference.” Generally speaking, you can add an overall quota for the entire drive or individual quotas for each person. The overall quota affects everyone who doesn’t have a specific individual quota.

OK, now you’ve configured the C drive to provide quota information in the form of event log entries. So, you create a test case to make sure everything works and that’s when you figure out that you can’t see any entries in the event log. In addition, it appears that the FSUtil Quota Violations command doesn’t work either. Well, that’s a little disappointing.

The problem is a lot simpler to correct than you might initially think. Microsoft hides the information you need in the Knowledge Base article at http://support.microsoft.com/kb/228812. The short story is that NTFS only scans the drive once an hour for violations, so you’ll have to wait a while to see any test violations. Of course, you might not have all day to wait around for NTFS to get around to scanning the drive. So, you can use the FSUtil Behavior Set QuotaNotify 60 command to set NTFS to scan the drive once a minute. In order to get this command to work, however, you must reboot the system. It seems that NTFS also loads its settings once during each boot cycle and then ignores the registry settings thereafter.

Once NTFS starts scanning the drive at a reasonable interval, you’ll begin seeing entries in the System event log. In addition, you can use the FSUtil Quota Violations command to look for violations as shown here:

At this point, you’re ready to go. Your system is setup to monitor quotas in a critical environment, but not to enforce the quotas (thus preventing people from completing tasks). I’ve had at least one person tell me that the FSUtil Quota Violations command tends not to work if the System event log gets too full; I’d like to find out whether other people are having the same problem. Let me know how you use quotas on your system at [email protected].

Regular Expressions with FindStr

Regular expressions are a powerful feature of the FindStr utility. However, they can also prove frustrating to use in some cases because the documentation Microsoft provides is lacking in good examples and difficult to follow. You can see some usage instructions for FindStr starting on page 82 of the Windows Command-Line Administration Instant Reference .

A reader recently commented that there is a problem with the dollar sign ($) regular expression. It must actually appear after the search term to be useful. Of course, the problem is creating a test file to sufficiently check the use of the regular expressions, so I came up with this test file:

Now, let’s perform some tests with it. Here is the result of some tests
that I performed using this test file and FindStr regular expressions:

The first test case shows what happens when you try
the command on page 82 of the book. It appears to work, but you’ll see
in a moment that it actually doesn’t. Let’s take the two parts of the
regular expression apart. Using FindStr “^Hello” *.TXT seems to work just fine. However, the command FindStr “$World” *.TXT doesn’t produce any output.
Only when the $ appears after World does the command produce an
output. Consequently, page 82 should show the rather counterintuitive
command, FindStr “^Hello World$” *.TXT to produce the correct output.

It’s also important to be careful about making generalizations when
using FindStr. For example, when working with the test file originally
shown in this example, the FindStr /B /C:”Hello World” *.TXT command produces the same output as FindStr “^Hello” *.TXT as shown here:

If you change the test file like this though:

you’ll see these results:

As you can see, you must exercise care when using FindStr to obtain the
desired results. What other odd things have you noticed when using
regular expressions with FindStr? Add a comment here or write me at [email protected] to let me know.