Categories Terminal Services

Writing Terminal Service Based Scripts (Part 13)

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

  • Writing Terminal Service Based Scripts (Part 2)
  • Writing Terminal Service Based Scripts (Part 3)
  • Writing Terminal Service Based Scripts (Part 4)
  • Writing Terminal Service Based Scripts (Part 5)
  • Writing Terminal Service Based Scripts (Part 6)
  • Writing Terminal Service Based Scripts (Part 7)
  • Writing Terminal Service Based Scripts (Part 8)
  • Writing Terminal Service Based Scripts (Part 9)
  • Writing Terminal Service Based Scripts (Part 10)
  • Writing Terminal Service Based Scripts (Part 11)
  • Writing Terminal Service Based Scripts (Part 12)
  • Writing Terminal Service Based Scripts (Part 14)
  • 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_server
    echo This subroutine allows you to choose a different server
    @Echo Off
    goto: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 Off
    Set /P _SRV=Please enter the name of the server that you want to work with
    goto: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 code
    goto: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% /Counter
    goto: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:

  • Writing Terminal Service Based Scripts (Part 2)
  • Writing Terminal Service Based Scripts (Part 3)
  • Writing Terminal Service Based Scripts (Part 4)
  • Writing Terminal Service Based Scripts (Part 5)
  • Writing Terminal Service Based Scripts (Part 6)
  • Writing Terminal Service Based Scripts (Part 7)
  • Writing Terminal Service Based Scripts (Part 8)
  • Writing Terminal Service Based Scripts (Part 9)
  • Writing Terminal Service Based Scripts (Part 10)
  • Writing Terminal Service Based Scripts (Part 11)
  • Writing Terminal Service Based Scripts (Part 12)
  • Writing Terminal Service Based Scripts (Part 14)
  • 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.

    Share
    Published by
    Brien Posey

    Recent Posts

    User-friendly web design tools for a user-friendly website

    If you want your business to succeed these days, you need a user-friendly website. Put these tools in your toolbox…

    10 hours ago

    New kids vs. old reliable: Can chat apps replace email?

    Do businesses rely too heavily on email for communication? Yes! Is the answer to replace email with chat apps? No!…

    14 hours ago

    PowerShell function to standardize message box script outputs

    If you got your start with Visual Basic, you remember msgbox. This PowerShell function will bring back memories and help…

    17 hours ago

    Microsoft Ignite 2019: Top announcements and product unveilings

    Microsoft Ignite 2019 included a slew of updates on products and services. Among the announcements was Azure Arc, which may…

    1 day ago

    Who says configuration management can’t be fun?

    Managing change in an enterprise isn’t easy and it’s usually no fun. Here’s a book on configuration management that will…

    2 days ago

    Choosing the right communication tools for your business

    Choosing communication tools is like choosing a first progamming language. While you want easy, you also want cross-platform, security, and…

    2 days ago