Scripting in a Server-Based Environment

I like to say that I became interested in terminal services because I was cheap and lazy. Cheap plays into it because of the upgrade cycle—any working environment that usefully extends the life of a client machine while letting me continue to use new versions of applications sounds good to me. (I still have a 486DX at home. Quit laughing—it makes a fine terminal client.) Lazy applies because I don't want to maintain many client seats. I’d rather concentrate on relatively few servers.

Laziness, properly applied, is a virtue. How about employing that virtue to exploit a feature of Windows 2000 Server (and Windows NT Server 4.0, Terminal Server Edition—TSE) to reduce server maintenance and client maintenance?

One of the best-kept secrets of Win2K is its support for scripting. Command-line support for NT utilities was (and is) minimal. It's better now than it has been in previous versions of NT. In fact, at one time, Microsoft said that with Win2K, you could do anything from the command line that you could do from the GUI. This is true—but mostly because of the powerful scripting tools available, not because Win2K provides a complete command-line toolbox. As you’ve seen from the "Keeping Up With Terminal Services" column, Microsoft has been considering how scripting works with Terminal Services, and with good reason: Terminal Services is a natural environment for using scripts to manage and monitor user environments.

I don’t have room for a long dissertation on Windows scripting here, but let me share the basics. Support for native scripting in Win2K and NT requires three components: two interfaces—Windows Management Instrumentation (WMI) and the Active Server Directory Interface (ADSI)—and the Windows Script Host (WSH), which offers an execution environment so that you can run Jscript or VBScript outside of a Web page. WMI abstracts interaction with many providers, including the Win32 subsystem on which Win2K depends, the registry, Performance Monitor, Active Directory (AD), and the Event Viewer. (That’s not all, but that’s a start.) ADSI is for manipulating namespaces such as AD and Novell Directory Services (NDS). You write a script in VBScript (called a consumer, in this context; other consumers are tools such as the Microsoft Management Console—MMC). Because your OS supports WSH, that script will run outside of a Web page. It queries an interface, and the interface translates the request into a form that the necessary provider can understand. The consumer doesn’t have to tune the request for a specific provider. And because WSH supports more than one language, you can write your script in any supported language, such as VBScript or JScript. Although only Win2K offers native support for WMI, you can download WMI support for TSE (or for regular NT 4.0 servers and even Windows 9x clients) from the Microsoft Web site.

Why use scripting in a server-based environment? Primarily because it’s one more way to reduce total cost of ownership (TCO). Part of the point of a thin-client environment is to reduce management. If you can keep an eye on your servers more easily, you’re reducing TCO further. For example, you’ll never get through all those event logs or alert logs, but you can certainly scan your email. With that in mind, you can create scripts to monitor free memory and send you email you if memory levels fall below a certain threshold. Another reason to use scripts is to streamline Remote Administration mode. As you know, you can install Terminal Services on Win2K Server for remote administration so that you don’t have to run from server to server. However, screen updates take time—even more time than flipping through the umpteen wizard screens. (Windows GUIs get simpler with each new version by asking fewer questions per screen, but for the same reason, they take longer to use.) Use scripting to speed common processes such as adding users or installing applications. If you can’t think of anything else to use scripting for, create logon scripts that assign printers to terminal users based on their log-in locations.

You can use scripting in innumerable ways to more effectively manage all kinds of servers—and that includes terminal servers. Let’s try an informal poll: Tell us how you use WSH with WMI and ADSI to manage terminal servers or terminal clients. And if you don't use WSH at all, why not?

P