In the previous article in this series, I took a step back and completed the script that I had originally started in Part 10. Now that you have learned how to accept user input, I am ready to revisit the script that I began constructing in Part 11.

Switching Terminal Servers

As you may recall from Part 11, one problem with the script that we were constructing was that it assumes that the requested operation needs to be performed against whatever machine you are currently attached to. This means that if you execute the script from your C: drive, then it will attempt to run the script against your local workstation. If you call the script from a network drive, then the script will run against the server that the drive is mapped to. This leaves far too much to chance. In order for our script to be useful, we need to know which server we are performing an operation against, and have the ability to switch to a different server if necessary.

As you may recall, we have already added some code that defines a default server, and that tells you which server you are currently attached to. We created a subroutine that will eventually allow us to switch servers, but as of right now that subroutine is empty.

Before we can write the code that allows us to select a different terminal server, we need to outline the steps that our script needs to perform. The first thing that the script needs to do is to query the network for a list of terminal servers. As you may recall from Part 2 of this series, there is a command named QUERY TERMSERVER that does just that.

One thing that you need to know about this command though is that it will only identify “true” terminal servers. Windows servers that have Remote Desktop enabled are technically acting as terminal servers, but they aren’t true terminal servers because they can only host an extremely limited number of sessions. That being the case, you will have to take this opportunity to assess your needs. I’m going to write this script in a way that allows it to identify true terminal servers. If you need to access servers that allow remote desktop sessions, then you will want to omit the QUERY TERMSERVER command.

Once we have identified a list of available servers, then we need to give the administrator a way of connecting to that server. Unfortunately, I don’t know of an easy way of channeling the server list into a menu. It can be done, but it takes a whole lot of work. Since that’s the case, we will prompt the administrator to enter the name of one of the servers on the list, and then assign that server name to a variable.

To make these modifications, we will be altering the subroutine sub_server. Here is what that subroutine currently looks like:

:sub_serverecho This subroutine allows you to choose a different server@Echo Offgoto:eof

As you can see, the subroutine doesn’t actually do anything at the moment other than displaying the phrase “This subroutine allows you to choose a different server”, and then terminating the script. The first change that I want to make is that I don’t want the script to terminate when the administrator picks a different server. Instead, the administrator should be returned to the main menu so that they can do something with the server that they have selected. Fortunately, this is a very easy change to implement.

The last line of the subroutine currently tells the script to go to the end of the file and then terminate. We can change this by changing the word EOF to LOOP. LOOP is the name of the subroutine used for the script’s main menu. This means that when Windows reaches the end of the subroutine, it will no longer terminate the script, but rather return to the script’s menu.

Allowing the administrator to change servers is almost as easy. We can simply ask for user input, and then assign that input to the _SRV variable, which is currently holding the name of our default server. Because the default server is being assigned before the script reaches the menu loop, returning to the menu loop will not cause our new server choice to be undone. In its completed form, this subroutine looks like this:

:sub_server@Echo OffSet /P _SRV=Please enter the name of the server that you want to work withgoto:Loop

Keep in mind that the subroutine for switching servers leaves a lot to chance. It is completely dependent on the administrator spelling the server’s name correctly, and entering the name of a valid terminal server. Unfortunately, doing any sort of serious error checking requires some rather advanced programming that is far beyond the scope of this article series. If you want to do some error checking, but want to take the easy way out, you can always work the PING command into the subroutine. We’ve already got the server’s name assigned to a variable _SRV, so you could ping the server as a way of testing to make sure that the named server at least exists by entering the following command:

Ping %_SRV%

Session Information

I have spent a lot of time developing, and helping you to understand the basic framework of our script. Now that we have the basic framework in place, it is easy to add terminal service related functionality to the script. As you may recall, our script currently has a few empty menu items connected to some empty subroutines. We can change these menu items to something terminal service related, and then alter the corresponding subroutines with terminal service related code.

As it stands right now, most of the menu choices link to an empty subroutine named sub_nothing (shown below). We can copy, and then rename this subroutine and use it as the basis for the subroutines that we have yet to create.

:sub_nothing echo Reserved for future codegoto:eof

Since the first terminal specific menu command that I want to make is related to session information, let’s create a copy of the subroutine and call it sub_session. Next, we will get rid of the echo command, and replace it with the QUERY SESSION command. You can see what the completed subroutine looks like below:

:sub_session Query Session /server:%_svr% /Countergoto:Loop

Notice that I have changed the last command in the subroutine to goto :loop so that the script will not terminate after the command is executed.

The Query Session command uses two switches. The first is the /server switch, which is used to direct the command against the server that the administrator has specified. The other switch is the /Counter switch. It’s an optional switch that provides us with a nice tally of sessions beneath the session list.

Conclusion

In this article, I have begun adding some terminal service specific commands to the script framework that we have already developed. In the next article in the series, we will create some more terminal service related subroutines.

If you would like to read the other parts in this article series please go to:

Featured Links

Read Next

Brien Posey

Brien Posey is a freelance technology author and speaker with over two decades of IT experience. Prior to going freelance, Brien was a CIO for a national chain of hospitals and healthcare facilities. He has also served as a network engineer for the United States Department of Defense at Fort Knox. In addition, Brien has worked as a network administrator for some of the largest insurance companies in America. To date, Brien has received Microsoft’s MVP award numerous times in categories including Windows Server, IIS, Exchange Server, and File Systems / Storage. You can visit Brien’s Website at: www.brienposey.com.

Featured Freeware

Recommended

Follow Us

Writing Terminal Service Based Scripts (Part 13)

TECHGENIX

TechGenix reaches millions of IT Professionals every month, and has set the standard for providing free technical content through its growing family of websites, empowering them with the answers and tools that are needed to set up, configure, maintain and enhance their networks.