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].