The next step is to find out what the values for that property mean. Some property values are easy to figure out. For example, for the Win32_TerminalServiceSetting class's ActiveDesktop property, it makes sense that a value of 1 enables Active Desktop and a value of 0 disables it. (It's a good idea, however, to double-check that property values mean what you think they do.) But some values are less intuitive—what does a value of 0 mean for the class's UserPermission property? To decipher such values, you can poke around GUI-based tools and mentally map GUI settings to class properties. In this case, a quick look at the Terminal Services Configuration tool reveals a User Permission setting, which has two possible values: a value of 0, which enables Full Security, and a value of 1, which enables Relaxed Security. Other resources that can help you track down the meaning of property values include the Microsoft Developer Network (MSDN) WMI Reference (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wmisdk/wmi/wmi_reference.asp) and Google (http://www.google.com).
Editing the Scriptomatic Script
After you run the Scriptomatic script to find the property information you need, you can save the script for editing. To do so, click the Save button to open a dialog box like the one that Figure 4 shows. Be sure to save the script as a .vbs file.
You can use Notepad or another text editor to edit the .vbs file. GetTSStatus.vbs, which Listing 1 shows, is an example of what the finished script might look like. This script retrieves and displays the Terminal Services settings for the local terminal server or for each specified terminal server. (The terminal servers must be running the WMI service.) To create GetTSStatus.vbs, I made two major modifications to the Scriptomatic script for the Win32_TerminalServiceSetting class:
Modification 1. I wanted to run my script on several servers, so I modified the Scriptomatic script so that it would run not only on the local terminal server but also on any specified remote terminal servers. I accomplished this capability with command-line arguments, an If...Then...Else statement, and a Select Case statement. I initially devised this system for a script that I discussed in "Check Service Status on Local or Remote Servers," March 2004, InstantDoc ID 41670.
To begin, I decided to use the following command to launch the script:
GetTSStatus.vbs [argument]
where argument can be one of the following:
One or more names of terminal servers, separated by a space
The word all (checks all the servers in Active Directory—AD)
The word file (an input file provides the terminal servers' names)
No argument is needed to run the script on the local terminal server.
When no command-line argument is present, the If...Then...Else statement that callout A shows tells the script to connect to the local terminal server. When an argument is present, the Select Case statement that callout B shows evaluates the argument to determine on which terminal servers the script should run.
If you plan to adapt GetTSStatus.vbs for use in your environment, you'll need to adapt the Select Case statement in two places. In the Case "file" code, you need to customize the INPUT_FILE_NAME constant. Replace C:\Scripts\Servers.txt with your input file's pathname. (In the input file, put each terminal server's name on a separate line.) In the Case "all" code, you need to customize the Set colComputers line. Replace LDAP://CN=Computers, DC=labyrinth, DC=com with the path to the servers on which you want to run the script.
Modification 2. Because I knew that I wanted to run GetTSStatus.vbs on more than one terminal server, I adapted the Scriptomatic script so that it includes the name of the server when it displays the server's Terminal Services settings. As callout C in Listing 1 shows, I accomplished this by adding the sComputerName variable (which contains the terminal server's name) to each Echo statement in the TSServStat subroutine.
What Scriptomatic Does Well
It's overstating the case to say that Scriptomatic will write your scripts for you while you work on your golf game or Space Invaders scores. The tool has a number of limitations, with the biggest limitation being that it creates scripts that do one thing and one thing only: spit out a class's property values. However, what Scriptomatic does do (and does well) is help you obtain WMI class and property information. After you have that information, you can create robust scripts that perform a variety of tasks.
You must be a registered user or online subscriber to comment on this article. Please log on before posting a comment. Are you a new visitor?
Register now
An often irreverent look at some of the week's other news, including some more Windows 7 sales momentum, some Sophos stupidity, Microsoft's cloud computing self-loathing, more whining from the browser makers, Zoho's "Fake Office," and much, much more ...
Let Your Users Reset Their Own Passwords: Free Download Try a 30 day free trial of Desktop Authority Password Self-Service – it provides an easy-to-use, robust system for allowing users to reset their own forgotten passwords or locked accounts.
Get Windows IT Pro & Mark Minasi’s Favorite Power Tools Guide Order Windows IT Pro now and get "More of Mark Minasi's Favorite Power Tools"--a in-depth guide to the most useful Windows commands --FREE with your paid order! Subscribe today, and save 58% off the cover price!
Deep Dive into VMware vSphere, eLearning Series Join John Savill to explore the major functionality capabilities of the vSphere virtualization platform, including identification of the changes from ESX 3.5.