Setting Up WebCheck

If you want to be notified immediately if your Web service or application goes down, the Microsoft Windows Internet Information Server Resource Kit's WebCheck utility is for you. You can use WebCheck to monitor Internet Information Server (IIS) and other aspects of a Windows NT system. This Visual Basic (VB) application is particularly useful if you can't easily gain access to your server to check it because you're on the road or managing a site remotely. In addition, you can run WebCheck from a scheduling system, such as the NT or Microsoft SQL Server scheduler, to regularly monitor your Web service and Web pages.

To monitor the Web service, WebCheck uses NT's Service Control Manager (SCM) to determine the service's status. WebCheck calls the OpenSCManager, OpenService, and QueryServiceStatus API functions to manipulate the SCM. If the service's current status isn't the status you want, the utility processes a notification message that contains information about the current status. You can have WebCheck mail you notification messages or log them in a database.

By default, WebCheck monitors the Web service (i.e., w3svc). However, you can configure WebCheck to monitor additional services.

To monitor a Web site, WebCheck uses wininet.dll's InternetOpen function to try to access a Web page in that site. If the server returns that page, the test is successful. If the server doesn't return that page, WebCheck mails or logs a notification message containing status information about the unsuccessful test. Because WebCheck uses the InternetOpen function, you can monitor Web pages on servers that reside not only in your LAN but also anywhere on the intranet or Internet, as long as an HTTP connection exists.

When you install WebCheck, the WebCheck folder appears in the C:iis resource kitutility directory. The WebCheck folder includes the Docs folder, which contains the WebCheck documentation, and the Source folder, which contains the utility's VB source code. VB developers or consultants can use the source code to easily modify WebCheck to meet specific needs. The WebCheck folder also includes a setup distribution that you can use to install WebCheck on additional systems.

Before you use WebCheck, you need to first create and configure a database, then configure WebCheck's configuration file, webcheck.ini. In addition, depending on your network, you might need to install WebCheck on additional systems.

How to Create and Configure the Database
The first step is to create the database to store the status information WebCheck returns. WebCheck supports SQL Server and Microsoft Access databases. In the following example, I created a SQL Server 7.0 database called WebCheck.

Screen 1 shows the database parameters I used. I set the database size to only 1MB because I was setting up a test system. When I use this database, SQL Server automatically expands the database if 1MB isn't large enough.

Next, you need to set up the database's structure and create the stored procedure that WebCheck requires. To set up the database's structure, I ran the table definition script in Listing 1 through the SQL Server Query Analyzer. To create the InsbndWebCheck stored procedure, I ran the SQL script in Listing 2 through the Query Analyzer.

Finally, you need to give the user who'll be running WebCheck permission to access the database. In SQL Server Enterprise Manager, open the Security folder. Right-click the Logins folder, and select New Login from the shortcut menu to display the properties that Screen 2 shows. Enter the user's name in the Name box, select the type of authentication you want to use, and specify the appropriate authentication information. For example, I entered WebCheck as the user's name, selected SQL Server authentication, and specified passme as the password. Select the Database Access tab to display the properties that Screen 3 shows. Select the database, and assign the user db_datareader and db_datawriter access. If you don't have permissions to make these changes, have your DBA perform these tasks for you.

To access the database, WebCheck reads the configuration information from webcheck.ini and uses the values to set the database parameters in the WebCheck application. The code that sets the database parameters is the ReadIniFileGlobals routine in modmain.bas, which is in the Source folder.

If you need to use a database other than SQL Server or Access (e.g., Oracle), you can modify the ReadIniFileGlobals routine to set the proper parameters (e.g., set the database type). You might also need to tweak the ADO code to support your particular database. You can check the Microsoft Web site and the database vendor's resources for more information about how to modify the routine and tweak the ADO code for your particular database.

How to Configure Webcheck.ini
As Listing 3 shows, webcheck.ini has five sections: [MAIN], [DATABASE], [SERVERn], [SERVERn:PAGEn], and [SERVERn:SERVICEn]. Each section has several entries that you configure. Although webcheck.doc defines the entries, they are worth covering because the documentation is cryptic.

The [MAIN] section has four entries that you need to configure. In the ServerTotal entry, you enter the number of servers you want WebCheck to test. In the DatabaseOrMail entry, you specify the type of notification to use. The possible notification types are Database, Mail, or Both. In the WebUser and WebPassword entries, you enter the security credentials to use for authorizing the user.

The [DATABASE] section defines several parameters for the database. If you select Database or Both as the notification type in the [MAIN] section's DatabaseOrMail entry, you use the Server and Database entries to specify where WebCheck is to log its notification messages. In the User and Password entries, you enter the security credentials that the database requires. (The WebUser and WebPassword entries in the [MAIN] section and the User and Password entries in the [DATABASE] section typically won't be the same.)

If you look in webcheck.doc, you won't find the TypeOfDatabase entry. I added this entry because WebCheck needs it to properly connect to the database. You enter either SQLServer or Access, depending on your database. Alternatively, you can specify just the letter S or A because WebCheck checks only the first character.

The [SERVERn] sections define the servers to test. The first server you define is Server1, the next server is Server2, and so on. You can define as many servers as you need. As a result, you can use one server to monitor several other servers. If you would rather provide redundancy in your testing, you can have several servers running WebCheck.

In each [SERVERn] section, you use the PageCount and ServiceCount entries to specify how many Web pages and services you want WebCheck to test on the specified server. For example, the entries in the [Server1] section of Listing 3, page 3, tell WebCheck to test one Web page and one service on the server named roughdraft.

The entries in the [SERVERn:PAGEn] sections define the Web pages to test. For each Web page you want to test, you need a [SERVERn:PAGEn] section. For example, to test page 1 on server 1, you need a [SERVER1:PAGE1] section. To test page 2 on server 1, you need a [SERVER1:PAGE2] section.

In the Page entry of a [SERVERn:PAGEn] section, you define the page to test by specifying that page's complete URL. In the Status entry, you enter the expected status return. Any other status return triggers a status email or database record. A 300 return value denotes a successful test; any other value indicates a problem.

If you select Mail as the type of notification in the [MAIN] section's DatabaseOrMail entry, you enter the email address of the person who is to receive the notification message in the MailTo entry. You can include more than one email address by using a comma- or semicolon-delimited list. For example, to generate notification messages to two recipients, you specify

[email protected];[email protected]

Whether you use a comma or a semicolon as a delimiter depends on the format of the mail system that WebCheck will use. WebCheck doesn't process the MailTo names; it only feeds them to the mail component.

The [SERVERn:SERVICEn] sections define the services to test. In the Name entry, you enter the service's short name (not the name in the Control Panel Services applet). You can find the various services' short names in the Registry at HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServices.

In the Status field, you specify the expected status return. You can set this field to any of these values:

*SERVICE_STOPPED
*SERVICE_CONTINUE_PENDING
*SERVICE_START_PENDING
*SERVICE_STOP_PENDING
*SERVICE_RUNNING
*SERVICE_PAUSE_PENDING
*SERVICE_PAUSED

As in the [SERVERn:PAGEn] section, the MailTo entry contains the email address of the person who is to receive notification messages (if applicable). After you configure webcheck.ini, place the file in the C:winnt directory.

How to Install WebCheck on Additional Systems
You can use the setup files in the WebCheck folder to install the WebCheck utility and its support files on additional systems. To start the setup process, run setup.exe from the WebCheck folder. Click OK in the first dialog box. The setup program then displays the dialog box that Screen 4 shows. If you want to change the default folder, click Change Directory. When you have the folder you want, click the button that shows the monitor icon to copy the WebCheck files and complete the installation.

The WebCheck files are now in the folder you selected. The folder contains a default webcheck.ini file. Change the default settings to match the servers and features you want to test. Place webcheck.ini in each WebCheck system's C:winnt folder. If you need to distribute this file to many WebCheck systems, you can customize the WebCheck VB source code so that all the WebCheck systems copy webcheck.ini from a central server location. Centralizing webcheck.ini makes placing and managing this file easier.

If you centralize the webcheck.ini file, you need to find all the entries in the source code that reference webcheck.ini and change those references to a network path. For example, in the code

g_lIniReturn = GetPrivateProfileString(g_siniSection,"Page", "", g_sTempIniString,Len(g_sTempIniString),"webcheck.ini")

you need to change the last argument "webcheck.ini" to a network path that specifies the file's new centralized location. (By default, the GetPrivateProfileString API function looks for webcheck.ini in the NT system directory.)

Customization Is Key
WebCheck is an effective monitoring tool for your servers because you can customize webcheck.ini and the system setup. Next month, I'll show you how to use Collaboration Data Objects (CDO) to further customize and automate WebCheck's email component. I'll also show you how to use Visual Studio's Package and Deployment Wizard to create a new setup package for WebCheck.