One of the most significant areas generally in Windows Server 2003 has been the improvements and increase in the availability, flexibility, and feature set offered by the command-line utilities.
Windows 2000 Server and Windows NT have always had a reasonable number of command-line tools, and there was talk before Windows 2000 and then again before Windows Server 2003 that the command-line interface would be removed entirely. In the end, the introduction of the Web Edition (which almost requires the command-line interface for some operations) and the extensive use of clients at the long end of a text-only network connection have led Microsoft to not only keep the Command Line Interface (CLI), but also extend it.
Ignoring the specifics of IIS for the moment, Windows Server 2003 incorporates command-line tools that control every aspect of the system.
Even additional features outside the core functionality of the OS are supported by command-line tools, and to an extent IIS is a part of this. The command-line tools in Windows Server 2003 are actually a mixture of direct execution tools and scripts that interface to one of the many interfaces available for administration. We'll have a look at the two main systems, known affectionately as AFSI and WMI, before taking a brief look at the command-line tools available.
Web Base Enterprise Management (WBEM) is an industry initiative to standardize the way we access and manipulate information for systems and network devices. WBEM is based on the Common Information Model (CIM)?a system for defining management information that was developed by the Distributed Management Task Force (DMTF).
Microsoft's implementation of the WBEM system is called the Windows Management Instrumentation (WMI). Within Windows Server 2003, the different areas of the OS are those supported by various WMI Providers, including IIS. Scripts, either running VBScript or JScript, can use the WMI Provider to write scripts to perform various tasks?and luckily Microsoft has provided us with a few examples.
Some of these scripts just provide an alternative way to configure or manage the system. Others actually provide a more useful way of displaying or collating information. For example, iisapp.vbs allows you to list all the configured applications?something you would otherwise have to trawl through IIS Manager to achieve. You can see a list of the WMI scripts in Table 4.2.
Lists the Web applications running on an IIS machine.
Backs up, restores, lists, and deletes IIS configurations.
Exports and imports IIS configurations from the Metabase (covered earlier in this chapter).
Enables and lists applications and Web service extensions and enables you to manage applications and extensions. Provides some of the functionality supported by the Web Services Extensions part of IIS Manager.
Allows you to create and manage FTP sites.
Creates and deletes virtual directories within FTP sites.
Creates and deletes virtual directories within Web sites.
Controls Web sites, allowing you to start, stop, create, or delete individual sites.
We unfortunately don't have room to cover all the ins and outs of the scripts; in fact, we've already covered some of the scripts in this and other chapters. If you want more help on these, either supply the /? or /help command-line option to the command for details on how to use it or check the online help.
Active Directory Services Infrastructure (ADSI) was available in Windows 2000 and provided a Common Object Model (COM) interface to systems configured and managed through the Active Directory as Active Directory Objects. The IIS ADSI provider provides scripted access to IIS properties, such as Web site configurations, directories, and applications.
In IIS 5, ADSI was seen as the way forward for command-line administration, but the WMI system has terminated that particular train of thought. Microsoft hasn't dumped ADSI yet though. ADSI in Windows Server 2003 has been updated to ADSI 2. Unfortunately, this means many of the scripts that work with ADSI won't work with ADSI 2. In particular, the new worker process and IIS 5 isolation modes and application pool systems will play havoc with scripts that update this information.
Telnet provides a command-line interface remotely over a network. Originally a Unix remote login tool, Telnet has now become a recognizable standard for command-line interaction with a number of operating systems.
Windows Server 2003, like Windows 2000, supports Telnet as a network service. By default it's disabled, but it can be started (and set to automatically start) by changing the properties of the service through the Services administration tool.
You can also start and stop the service by using the tlntadmn command, although this does not change the default startup mode. The tlntadmn command is also the best to set Telnet options, such as the timeout period, the maximum number of connections, and telnet port number.
Although you still need a valid login and password for Telnet access, the information is still transferred in plain text. If you want a more secure solution, you might want to consider the Secure Shell (SSH) system. This provides a secure, encrypted communication channel using the same basic transport protocol as Telnet, so you can still have command-line access. You can find a Windows version of the SSH server at OpenSSH.org and an SSH and Telnet client called PuTTY at http://www.chiark.greenend.org.uk/~sgtatham/putty/.
For clients, all Windows implementations support a basic telnet client. In earlier implementations this is a separate application, but within Windows XP and Windows Server 2003, it's a command-line level tool that works entirely within the confines of a command prompt.
Recent versions of HyperTerminal also include Telnet support. There's also a wide range of freely available Telnet clients, including my favorite, PuTTY.