A few days ago at work, I went to connect to a headless server at work, and it indicated that I couldn’t connect because all the Terminal Services connections were in use. What now?

There are graceful ways around the issue. You can (a) Reset one of the connections remotely, freeing up room for you, or (b) Connect to the computer’s console session and then reset the sessions from a GUI interface.

Resetting connections remotely. This method is more graceful, but requires a bit more work. As Scott Forsyth described in Managing Terminal Services Sessions Remotely, the qwinsta (query windows station) and rwinsta (reset windows station) commands can help you accomplish this.

Use qwinsta to find a session to clear, or reset:

C:>qwinsta /server:MyServerName
SESSIONNAME USERNAME ID STATE TYPE DEVICE
0 Disc rdpwd
rdp-tcp 65536 Listen rdpwd
console 5 Conn wdcon
rdp-tcp#59 MyUserName 2 Active rdpwd

In this example, “MyUserName” has a session, and I could clear that session to take it’s place. To do that, I would use rwinsta to clear the session, which has an ID of 2:

C:>rwinsta 2 /server:MyServerName /V
Resetting session ID 2
Session ID 2 has been reset

With the session being reset, I could now successfully login with Remote Desktop.

Connecting to a console session. Windows will always have a console session, which is the session that represents the session outputting to the physical monitor, if one were plugged in. If a user were logged into the machine and physically using the mouse, keyboard, and monitor that are plugged into the machine, and you then connected remotely to the console session, their session would be disconnected and you would connect to that console session. Obviously, this is not the typical approach you would want to take, but it is an option when you need to force yourself onto the computer.

Basically, this is accomplished by running Remote Desktop from the command line (mstsc) and invoking the command line argument to connect to the console session.

mstsc -v:MyServerName -console

That’s all there is to it! At that point, you can either proceed with your work or use the console session to clear any other Terminal Services sessions in the Terminal Services control panel.

Back in the day, I used to always love mentioning the supposed quote from Bill Gates, which would have marked him as significantly short-sighted: “640k is more memory than anyone will ever need”, or some close variant thereof.

We love to quote it, because we love to hate Bill Gates and yet we can relate with the amazement of ever greater RAM requirements. For instance, I never thought when my powerhouse Mac came with 128MB of RAM that one day I would have a Mac with a video card holding more RAM than that! Insert similar nostalgic reflection here, ad nauseam.

Well, now I can just feel stupid and short-sighted without pointing the finger at Bill Gates. I never even thought to verify the quote until today for some unknown reason I decided to. Sure enough, you’ll be hard-pressed to find an official citation, and Bill Gates denied ever saying that.

It’s easy to backup or restore your database directly with SQL.

backup database MyDatabase TO DISK=‘c:pathtoMyDatabase.bak’ with INIT

The syntax is pretty self-explanatory once you see it. Backup the database “TO DISK”, or to a file at the designated path. The “WITH INIT” specifies that any existing backup file will be overwritten.

The restore syntax is nearly identical. If the database you are restoring currently exists, be sure to drop the database before doing the restore.

restore database MyDatabase FROM DISK=‘c:pathtoMyDatabase.bak’

Simple as that.

Microsoft’s Command Redirection Operators page provides the factual information on how to do redirection, but actual implementation gets a bit confusing for anything beyond command > filename.txt. Here’s a rundown on how to do some useful things. I’m not going to cover every aspect of redirection, but I’ll point you to the cases I find myself in most often.

The basics. You want to generate either a log file or a file that you will be executing after you’re done generating it. You’ll likely be using a combination of echo commands as well as some output from a handful of commands. Welcome to the > and >> operators. The first will send the output to a file and erase its existing contents; the second will append the output to the file.

Examples:

# This will send the dir command’s output to a fresh file:
dir > myfile.txt

# Here I will create a fresh file with an echo command,
# and append the dir output to that:
echo Here is a directory > myfile.txt
dir >> myfile.txt

Redirection for logging. This is a great way to make log files, which can even have the date and time with a simple improvement over that last example:

echo %date%, %time%: Listing a directory. > myfile.txt
dir >> myfile.txt

Using this technique, you can log not just what your batch scripts are trying to do, but what the results are. For instance, let’s say we’re generating a batch script that automatically creates accounts and drops them in a group. If I’m doing this in AD, I might have code like this:

# Add user “joe” to the “MyGroup” group.
net group MyGroup joe /add

To log the result of this, I might try:

net group MyGroup joe /add >> AddAccts.log

Better error logging. When this command succeeds, it outputs, “This command completed successfully.” It will output this to the log file, and you know the net group command succeeded. However, if there were errors, it will output, “The command completed with one or more errors.” However, the standard output doesn’t include the actual error messages, even though you can see them outputting to the screen. This is because there is a separate error stream, and by default, the redirection operator only streams the standard output.

This is where the >& operator comes in. This will pass the output from one “stream”, or “handle” into another. This means you can take a command’s error stream, and pass it into its output stream, so that both standard output and error output will be together.

Everything thus far was in Microsoft’s documentation page I referred to earlier. But now how do you use the >& operator? I stumbled across Eric Jarvi’s blog post, “Redirecting stderr to stdout on the command line“, which has an example in the comments.

A quick preface: The standard output stream has a handle of 1, and the error stream has a handle of 2. That being said, take the above example, and modify it like this so that both stdout and stderr will stream to your file:

net group MyGroup joe /add 1>>AddAccts.log 2>&1

This code is effectively saying: “Perform the net group command, then output the stdout to AddAccts.log, but also redirect the stderr stream into the stdout stream at the same time.”

As a result, you have stdout and stderr both in your file. Your log will now give you much more meaningful feedback on any errors your batch scripts might be encountering.

Whereas other forms of redirection are very useful (such as the | pipe), I find the above operators the most commonly used in my development.