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 farnow 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


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 placeTelnet 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 itthe 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 safeit 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 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 packetseach 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 anythingyou 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


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


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.


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.


Simulating Users with the RunAs Command

One of the problems with writing applications, administering any network, or understanding system issues is to ensure that you see things from the user’s perspective. It doesn’t matter what your forte might be (programmer, administrator, DBA, manager, or the like), getting the user view of things is essential or your efforts are doomed to failure. Of course, this means seeing what the user sees. Anyone can run an application at the administrator level with good success, but the user level is another story because the user might not have access to resources or rights to perform tasks correctly.

Most knowledgeable users know that you can simulate an administrator by right clicking the application and choosing Run As Administrator from the context menu. In fact, if you Shift+Right Click the application, you’ll see an entry for Run As A Different User on the context menu that allows you to start the application as any user on the system. However, the GUI has limitations, including an inability to use this approach for batch testing of an application. In addition, this approach uses the RunAs command defaults, such as loading the user’s profile, which could cause the application to react differently than it does on the user’s system because it can’t find the resources it needs on your system.

A more practical approach is to use the RunAs command directly to get the job done. You can see some basic coverage of this command on page 480 of Windows Command-Line Administration Instant Reference. To gain a basic appreciation of how the user views things, simply type RunAs /User:UserName Command and press Enter (where UserName is the user’s fully qualified logon name including domain and Command is the command you wish to test). For example, if you want to see how Notepad works for user John, you’d type RunAs /User:John Notepad and press Enter. At this point, the RunAs command will ask for the user’s password. You’ll need to ask the user to enter it for you, but at that point, you can work with the application precisely as the user works with it.

Of course, many commands require that you provide command line arguments. In order to use command line arguments, you must enclose the entire command in double quotes. For example, if you want to open a file named Output.TXT located in the C:\MyDocs folder using Notepad and see it in precisely the same way that the user sees it, you’d type RunAs /User:John “Notepad C:\MyDocs\Output.TXT” and press Enter.

In some cases, you need to test the application using the users credentials, but find that the user’s profile gets in the way. The user’s system probably isn’t set up the same as your system, so you need your profile so that the system can find things on your machine and not on the user’s machine. In this case, you add the /NoProfile command line switch to use your profile. It’s a good idea to try the command with the user’s profile first, just to get things as close as you can to what the user sees. The default is to load the user’s profile, so you don’t have to do anything special to obtain this effect.

An entire group of users might experience a problem with an application. In this case, you don’t necessarily want to test with a particular user’s account, but with a specific trust level. You can see the trust levels setup on your system by typing RunAs /ShowTrustLevels and pressing Enter. To run an application using a trust level, use the /TrustLevel command line switch. For example, to open Output.TXT as a basic user, you’d type RunAs /TrustLevel:0x20000 “Notepad C:\MyDocs\Output.TXT” and press Enter. The basic trust levels are:


  • 0x40000 – System
  • 0x30000 – Administrator
  • 0x20000 – Basic User
  • 0x10000 – Untrusted User

Many people are experiencing problems using the /ShowTrustLevels and /TrustLevel command line switches with newer versions of Windows such as Vista and Windows 7. The consensus seems to be that Microsoft has changed things with the introduction of UAC and that you’ll need to work with the new Elevation Power Toys to get the job done. I’d be interested in hearing about people’s experiences. Contact me at

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


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.

Call Batch2.BAT
Call Batch2.BAT Passed %1 "%PATH%"
ECHO In Batch 1
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

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

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