The Microsoft Windows Internet Information Server Resource Kit is a collection of utilities, components, tools, and applications that are useful in developing intranet or Internet applications or for application management. (For information about resource kits in general, see the sidebar "What Is a Resource Kit?" page 2.) This resource kit contains a wealth of information about IIS and offers tremendous value to the systems or Web administrator. After you install the resource kit, you can take advantage of its many tools, including Metabase Editor, an HTML version of Microsoft Transaction Server (MTS) Explorer, Admin Scripts, ADOSelect, WebCheck, and the Web Capacity Analysis Tool (WCAT).
Installation Process
When you install the resource kit on your IIS server, it stores files in C:\IIS Resource Kit and creates the Internet Information Server Resource Kit folder on the Programs menu. However, installation doesn't automatically load all applications and files; it puts the files and the application setup files in the IIS Resource Kit directory and links the README and installation files to entries on the Programs menu.
To install a utility, you execute the Install command from the Programs menu. After installation, you can remove the utility's setup files from the disk. However, before you do, make sure they really are the setup files because the resource kit doesn't install or configure all utilities and applications in the same way. For example, some utilities such as Metabase Editor have setup files in the utility's directory—MetaEdit, in this case—and others have setup and configuration files in other directories or different formats.
The installation program creates a new virtual directory, IISResourceKit, under the default Web root, \InetPub\WWWRoot, and automatically configures this directory as an Active Server Pages (ASP) application. The installation process installs the resource kit's Web utilities in IISResourceKit, which contains ASP samples and utilities with Web interfaces.
IIS uses the metabase instead of the Registry to store most of its configuration information, relieving the Registry of the additional load and keeping the Registry smaller and less complex. The downside to using the metabase is its proprietary format, which makes it more difficult to access or modify. However, you can use IIS management tools or the programmable interface, Metabase Editor, to modify the metabase.
Metabase Editor
Metabase Editor lets you peek into the mysterious metabase and see what Internet Service Manager (ISM) or other utilities are doing to IIS's configuration parameters. Metabase Editor is a Windows Explorer-like tool that lets you access and change information in the metabase. Screen 1 shows the Metabase Editor interface.
To install Metabase Editor, execute the Install MetaEdit command from Programs, Internet Information Server Resource Kit, Utility, MetaEdit. Install MetaEdit runs the Setup program, which adds Metabase Editor to the MetaEdit folder off the Programs menu. By default, Setup installs the program in the \Program Files\MetaEdit directory. You can change this default directory during setup, if you want. When you start Metabase Editor, it opens with its folders compressed.
Installing and opening Metabase Editor is only part of the equation. You also need to understand the metabase's structure and its various settings—a task similar in complexity to understanding the Registry. The metabase settings aren't well documented, so you must research Web sites (e.g., http://www.microsoft.com, http://www.15seconds.com) or explore the metabase to find the various entries and their possible values. For example, if you explore the LM\W3SVC tree, you'll find that it contains the settings for the virtual directories. The default Web site is folder 1, and the Administration Web site is folder 2. As Screen 2 shows, you must expand the Root entry under each folder to see the virtual directory settings for that Web site.
You can also explore Metabase Editor's entries and values by using ISM to modify the IIS configuration and then Metabase Editor to see how your changes affected the metabase. For example, if you use ISM to change the Isolated Application setting to True and then use Metabase Editor to check the AppIsolated flag in the metabase, you'll find that the AppIsolated flag has changed from 0 to 1.
Use Metabase Editor with the same caution that you would any Registry editor. You can easily destroy the IIS configuration or a particular virtual directory if you're not careful.
HTML MTS Explorer
Another useful utility is the HTML version of MTS Explorer. This ASP application lets you manage MTS remotely over HTTP from a browser—an extremely useful capability if you travel frequently or use a platform that doesn't support MTS Explorer. The HTML version of MTS Explorer works in a manner similar to the HTML version of ISM. (For information about ISM, see the Windows NT Magazine article "The Dexterous HTML-based ISM," June 1999.) Interfaces and behaviors are also similar between the two because both rely on HTML capabilities such as hyperlinks for most features.
Installing the resource kit installs HTML MTS Explorer on the Administration Web site. This site has a unique assigned port number to prevent unauthorized users from accessing it. By default, the Administration Web site is also set to prohibit remote access. The security settings on my server allow access only from IP address 127.0.0.1, which is my local system. Trying to access the server from any other system results in an error.
You can change the valid security settings on the Directory Security, Properties page for the Administration Web site by editing the IP Address and Domain Name Restrictions to allow access by other systems. Screen 3 shows the dialog box on my system after this change. You can also restrict Administration Web site access to selected IP addresses by entering those addresses in this dialog box.
After you've configured the security settings, you can access the HTML version of MTS Explorer. The URL will look similar to http://abaco:9008/ mtsadmin. This URL starts the default page for mtx.asp (i.e., MTS Explorer) on the server abaco, which uses port 9008 for the IIS Administration Web site. (Your server name and port number will differ according to your system.) The first view of mtx.asp shows its packages in the left pane. To expand a package and see its contents, simply click the package name.
ADSI Admin Scripts
The resource kit includes a set of Admin Scripts that you can use to help administer IIS. These scripts are in the \IIS Resource Kit\Utility\ADSI Admin Scripts directory. The scripts use Active Directory Service Interfaces (ADSI) to access IIS and other servers and to carry out the actions that the scripts automate.
The Admin Scripts are really a starting point; an administrator can modify them to perform custom tasks, such as creating new virtual roots and other Administration tasks. The Admin Scripts aren't perfect, however, and serve only as general-purpose samples, so be careful. If you manage only one or two servers, you might not need these scripts. However, if you manage a server farm, finding out what's in the scripts and how to modify them can make managing your servers much easier.
ADOSelect
Another convenient utility is ADOSelect. To implement this utility, use the adoselect.asp file installed in the ADOSelect directory in the IISResourceKit virtual directory. ADOSelect is handy for testing ADO or a database on an IIS server or for issuing a query against a table. This utility can save a lot of time when you configure a new server, install or maintain a database server, or install a new version of ADO or an application. Installing a new version of ADO and having applications break is extremely frustrating. With ADOSelect, you can quickly test ADO and the database and determine whether the fault lies with one of those technologies.
To access ADOSelect, type the following URL in your browser: http://server name/iisresourcekit/ adoselect/adoselect.asp. Replace server name with the name of the server where your IISResourceKit virtual directory resides, and press Enter. You can use a system Data Source Name (DSN), as the text on the ADOSelect page indicates, or you can enter a connectionless DSN. For example, I used the following string in the DSN field to connect to the Pubs database:
dsn=pubs;uid=sa;pwd=;
To use a system DSN name, such as Pubs, you must supply the correct user account and password for the data you want to access. You can enter either a simple table name or a combination of table name, column name, and value to query against. Supplying a query value adds a Where clause to the SQL statement that the DSN string generates and returns only the rows matching the value you entered.
If you need to test your database frequently, you can modify adoselect.asp to test a specific database or create your own ASP code to test particular functions of a database or ADO. If your applications use COM objects, you can create test ASP to exercise the objects that use ADO.
WebCheck
ADOSelect is fine for testing ADO and the database in an ad hoc mode, but using the WebCheck utility to notify you that your Web server or application is down is a better routine monitoring service for Web applications. Problem notification is particularly handy if you're on the road or manage a site remotely and can't easily gain access to the server to check it.
WebCheck is a Microsoft Visual Basic (VB) application that monitors services and Web pages on a server. This utility uses Windows NT's Service Control Manager (SCM) to check the status of a service and create and send a notification message containing the status information. WebCheck can also test Web pages to determine whether IIS and the Web application are operational. If the Web page returns, the test was successful and WebCheck creates and sends a notification message containing the status information. This utility can send notification to an email address or log it on a database. The configuration parameters in the WebCheck confirmation file determine what type of message notification to use.
The source code for the WebCheck application comes with the utility, and you can modify the source code to suit your needs. Because the application is written in VB, a VB developer or a consultant can easily modify the application and customize it to your organization's needs.
I recommend that you use a scheduling system such as the Windows NT scheduler or the Microsoft SQL Server scheduler to execute the WebCheck utility (webcheck.exe) periodically to monitor the items listed in the WebCheck configuration file (webcheck.ini). You must put webcheck.ini in the C:\winnt directory (or your root Windows directory) for webcheck.exe to find it.
A document (webcheck.doc) in the \WebCheck\Docs directory defines the entries for webcheck.ini. The documentation about webcheck.doc is terse, so a description of what this document contains is worth mentioning. Listing 1 shows an example of the various sections you'll find in webcheck.doc. (In the entries with server_name and email_address, you'd find your server name and the email address of the person you want to notify.)
The \[Main\] section defines the number of servers and the type of notification you want to use. The notification types are Database, Mail, or Both. Other entries define the security credentials required for user authorization.
The \[Database\] section defines several parameters for the database. The Server and Database entries define the database to connect to for database notifications. The User and Password entries define the security credentials required for the database.
When I was setting up the \[Database\] section, I found that webcheck.doc didn't define one parameter I needed in webcheck.ini: TypeOfDatabase. Therefore, I added the following parameter to point to the WebCheck SQL Server database on my server:
TypeOfDatabase=SQLServer
The \[ServerX\] sections define the parameters for each server tested. The first server is Server1, the second server is Server2, and so on. Each \[ServerX\] section defines the server's name and the number of Web pages and services to test. The remaining entries from the sample webcheck.ini define the Web pages and services to test. The header for each section defines the server and Web page numbers to test.
WebCheck is a good example of how to set up monitoring for a server. You can customize WebCheck or use ideas from it to create a more extensive monitoring tool for your server. Web page monitoring is interesting because it uses the wininet.dll InternetOpen function to retrieve the Web pages to test. Thus, the application can monitor Web applications on servers not on your LAN. You can monitor servers anywhere on the intranet or Internet as long as an HTTP connection to the server exists.
WCAT
The last utility I want to cover in this article is WCAT, which measures the capacity potential of an IIS installation under a variety of client workload simulations. (You can get this tool from the resource kit or from the Microsoft Web site at http://msdn.microsoft.com/workshop/ server/toolbox/wcat.asp.) When you install this tool, you get a users guide, wcatguide.doc. The WCAT installation files are in the WCAT directory on the server disk you selected. Execute \WCAT\setup.exe, which the resource kit installs, to install WCAT files on your server.
WCAT is useful to test the capacity of a Web server or an application. This utility simulates loads against a Web server and logs the results. You can use WCAT to test a server and get a good idea of how that server will perform when it runs ASP or HTML applications.
Chock Full of Goodies
The resource kit is full of information and tools to help you manage your Web servers and build Web applications. Many of the utilities and other programs in the resource kit also include source code that you can use to modify the applications. If you don't already have the resource kit, make it your next purchase.
