Why would users with no administrative duties who have powerful computers capable of running their applications locally need a terminal connection? Here's one reason: They're developers. Having developers use terminal connections isn't necessarily a new idea in server-based computing, but I think it's worth a second look. Lately, I've spent a lot of time experimenting with Windows Management Instrumentation (WMI) and Active Directory Service Interfaces (ADSI) and other Windows scripting technologies, and writing and testing scripts to see what works and what doesn't. I've found a terminal connection to be incredibly useful in the development process.
First, the terminal connection lets me run scripts designed for local use on a variety of platforms without having to get up and move. A developer who runs a terminal session from Windows NT 4.0 or Windows 98 will be able to test cross-OS compatibility and find out how well a script written on one platform runs on another platform.
Second, terminal sessions are useful for checking out the results of a script designed for remote management. Although you might think I could check the results of my remote-management scripts by running a second script to check object properties after I edit them, this doesn't always work. For better performance, WMI (for managing computer resources and environment) and ADSI (for managing objects stored in a directory service) cache object properties on the computer that runs the script. After the information is cached, the scripts read from the cache, not from the remote computer, which can make it difficult to determine whether the changes took effect. But by running a remote desktop to the servers I used to test the scripts, I could see whether my changes had been applied. This method was handy, it was fast, and it was a heck of a lot more convenient than walking around to check the test servers. (When I tested my scripts, I spent some time bemoaning NT 4.0's lack of terminal services support, because any time I wanted to see the effects of a script on an NT server I had to walk over to the machine to look at the console.
This is one time when licensing also can work in your favor. If you've set up a test lab with Windows 2000 servers, each of those servers will accept up to two administrative connections. Because you're running terminal services in Remote Administration mode, you don't need a Terminal Server Client Access License (TSCAL). Thus, this kind of testing environment is essentially free for anyone who likes to test scripts before putting them on production servers.
Administrative scripting isn't exactly new or exclusive to Win2K, but in Win2K it's more powerful and much more accessible than the scripting capabilities available to you in previous versions of NT. If you get around to experimenting with scripting, I think you'll find a window on a remote server (one accessible to developers only, please—I don't think production workers want to use the server on which someone else is testing scripts) is an incredibly useful development tool.
End of Article
