Chapter 7

Running the Intranet Web Server

CONTENTS

• Configuring IIS
• Publishing Existing Documentation on Your Web
• Helper Applications for Your Customers
• Summary

With much of the theoretical material behind you, now is finally the time you can begin to establish a real Intranet. In this chapter, you'll set up the IIS Web server and take your first steps to publish existing corporate or organizational information on your Intranet. As you go through this chapter, you'll see real examples of how to jump-start an Intranet using various tools and techniques. When you finish this chapter, your Intranet will not be complete by any means, but you'll have made a good start.

Configuring IIS

Whether you downloaded IIS for free from the Microsoft Web site or obtained it from the CD-ROM with Windows NT, I'll assume at this point that you have followed the installation instructions that came with the software. Now the trick is getting it to work. Actually, depending on the state of your configuration, you may need several tricks.

By the time you read this, Microsoft will have released version 2.0 of IIS (anticipated with NT 4). Today I'm working with the beta release of version 2.0, and judging by the issues that I've faced with it and what I've heard from many other users on the Internet newsgroups, some aspects of configuration are not very intuitive. However, I think this difficulty is largely due to the fact that IIS is such a new product; the user community needs time to become aware of its features. After you get it up and running, you should be very pleased with its performance, features, and security.

Starting the Services

After installing IIS, you can run the Microsoft Internet Services Manager (shown in Figure 7.1) by choosing Start | Programs | Microsoft Internet Server | Internet Service Manager. The first thing you want to do is get the WWW Publishing Service started. Select that item in the list, and then click the triangle icon in the toolbar or choose Properties | Start Service.

Figure 7.1: The Microsoft Internet Service Manager with no Service started.

If the service starts, you should be able to use your Web browser to visit the sample home page installed by IIS. (See Figure 7.2.)

Figure 7.2: The Sample home page installed IIS is the first place to test the WWW Publishing Service.

But what if the service won't start? The most likely cause is that a dependency service is not already running. Unfortunately, IIS won't always tell you which service it depends on, but I learned the hard way that it is probably the Remote Procedure Call (Rpc) service. In case you don't already have the Rpc service running, choose Start | Settings | Control Panel | Services. Scroll down to the Rpc Service, click Startup, and choose Automatic. The Automatic setting tells NT to start the service during bootup. It does not start the service immediately, and you don't need to reboot to make this setting work. Just click the Start button so your screen looks like Figure 7.3.

Figure 7.3: The Rpc Service should be started for IIS.

Now you should be ready to start the WWW Publishing Service. You can either do that in the Control Panel Services dialog (while you're there), or you can do it in the IIS GUI. They both have the same effect.

Configuring the WWW Publishing Service

After you have the WWW Publishing Service started, you can double-click the WWW item in the IIS Service Manager list to configure the Service properties. Figure 7.4 shows an example configuration of the Service tab.

Figure 7.4: The WWW Service needs to run within the context of a User account.

The most important thing to note is that IIS created a default User account for itself when it installed. You will want to run User Manager for Domains (on NT Server) to configure the account permissions for the user that IIS creates. By default, the account name is IUSR_computername (where computername is replaced by the actual NetBEUI host name of your machine).

The purpose of this account is to let you, as the system administrator, configure the permissions of IIS when it is acting on behalf of an anonymous user. For example, if I connect with my Web browser to your WWW service, the WWW service better have Read permission to the HTML root directory so that it can send the files to my browser through HTTP. Similarly, you will want the service to have Execute permission on the directory where CGI and ISAPI applications are located.

You'll want to ensure that the user account in User Manager is maintained in a compatible manner with the Service tab in IIS. This compatibility is very important; the passwords must match, and the user account must be given the permission to log on locally. To enable the account to log on locally, follow these steps:

1. Choose Start | Programs | Administrative Tools | User Manager for Domains | Policies | User Rights. A dialog box appears.
2. Check the box labeled Show Advanced User Rights.
3. Scroll down in the drop-down list labeled Right until you see Log on locally. Select that item.
4. If you do not see the IUSR_computername account in the Grant To list box, click the Add button to add that right to that user. Your dialog should look similar to Figure 7.5 when you are done. Interestingly, the IUSR account does not need the right to log on as a service.

Figure 7.5: The IUSR account needs the right to log on locally.

The next step in the process is to ensure that the IUSR account has the correct permissions to access the directories containing the HTML documents. If you installed IIS on an NTFS volume (recommended), you can do this step in Explorer by right-clicking each folder that contains HTML files and then choosing Properties | Permissions.

I'll have more to say about security in Chapter 10, "Intranet Security in Windows NT," but there are a couple of other nuances that I should mention here. The IUSR account will need to have appropriate permissions within the domain if you expect it to serve documents from virtual directories on other machines in the network. To serve documents from another machine on the same LAN with the IIS machine, the virtual directory must use a Unc path. And the virtual directory must be within the same domain where IIS is running.

Configuring the WWW Service Directories

The Directories tab in the WWW Service dialog allows you to create reference names (called aliases) for directories on your server where you store HTML documents to be served. As you can see in Figure 7.6, there are two checkboxes in the Directories tab of this dialog. The checkboxes are self-explanatory. If you place a file named default.htm (you can choose a different default name in the dialog) in each subdirectory that is served by the WWW Service, a client browser will not need to specify the full filename in the URL.

Figure 7.6: The Directory configuration tab in the WWW Service dialog.

If you check the Directory Browsing Allowed box, and you don't have a file named default.htm in each subdirectory under the <Home> directory, the client browser will be given a complete listing of all the files in the subdirectory that don't specify a full URL with a filename.

Configuring the Logging and Advanced WWW Settings

The remaining two tabs in the WWW Service dialog deal with security: Logging and Advanced Access Control.

If you want to keep track of who is visiting your Web server, and you don't mind taking a small performance hit while the server writes that information to a file or a database, you can enable logging. As shown in Figure 7.7, the Logging dialog is very straightforward. File logging is recommended for better performance, and it should be sufficient unless you want to set up some nifty SQL queries of your own to monitor the log files. I don't imagine that logging would be a big issue on an Intranet; ideally you want all your customers to use the Web server. Logging is more for the purpose of security on an Internet Web site.

Figure 7.7: The Logging configuration tab in the WWW Service dialog allows you to monitor who is visiting your Intranet server.

The Advanced tab is also more of an Internet versus Intranet issue. But if you want to exclude certain machines on your LAN from having access to the Web server, you can enter those IP addresses in the dialog shown in Figure 7.8.

Figure 7.8: The Advanced configuration tab in the WWW Service dialog allows you to grant or deny access by IP address.

Publishing Existing Documentation on Your Web

Now that the IIS WWW Service is up and running, turn your attention to the documents that you will serve from your Intranet home page. The main source of information for your Intranet is the body of documents and data you already have available. This data, particularly if it's already in electronic format, will form your Intranet's foundation.

Taking Inventory

If yours is a typical organization, you probably have a lot of potential Intranet information lying around in file cabinets and on bookshelves and computer disks. Before you dive into the later sections of this book, dig up all this existing information and determine how much of it you can make available on your Intranet without too much time and effort.

Begin this process by taking inventory of the information already available in your company. Look for items such as the following:

• The company phone book
• Other informational material for employees, such as bulletin boards, job postings, and in-house newsletters or publications
• Employee benefits information
• Manuals of operational procedures
• Catalog and inventory lists
• Stored letters, memoranda, and other word processing documents from active disk drives or on backup tapes or disks
• Anything else you might find around the office, in a file cabinet, in a drawer, on a bookshelf, or even tacked on a wall or bulletin board

Casting a wide net at this point is important. Think of your Intranet as a big bank of filing cabinets, containing every piece of paper and scrap of data your company owns. You save information in filing cabinets because someone might need to look up the information in the future. The same goes for the information you'll put into your Intranet; anything that someone might need in the future is a candidate for inclusion.

After identifying the total pool of available data, the next question is which of that information can you easily make available on your Intranet? Not all of your data can be included with equal ease, so you'll need to evaluate which information is worth the time and effort necessary to make it usable on your Intranet.

The Easy Part First

Obviously, material that's already in electronic format is your prime and most accessible source of Intranet data. Within this category, old word processing documents will likely be the single best source of information, particularly if your organization uses formal electronic filing procedures of some kind. Even if you have no document-management apparatus, you'll probably find important recent documents still sitting on your hard drive or on backup tapes, just waiting to be put on your Intranet.

Your word processor's Save As feature is one of the most powerful tools for putting your word processing documents on your Intranet. All modern word processors have a Save As feature, which enables you to quickly convert the word processor's documents to plain text files, also called ASCII text files. Plain text files are directly usable in your Intranet. You can place them on your Web server as-is, with no further conversion. From there, your customers can view them with their Web browsers.

Suppose you have Microsoft Word, but you don't have Internet Assistant for Microsoft Word installed. When you choose File | Save As in the Word menu, you will see a scrollable list of file formats in which you can save documents. But if you search for plain ASCII text you won't find it-Word calls it Text Only with Line Breaks. WordPerfect has a similar option.

The default filename for converted documents in both Word and WordPerfect uses the extension .txt. You should accept this default extension because the plain text MIME data type/subtype, which uses the .txt extension, is directly supported by all Web servers and browsers. (Refer to Chapter 12, "MIME and Helper Applications," for information about MIME data types/subtypes.)

This simple Save As feature can make it possible for you to create a large library of documents for your Intranet in a very short time. Just load the document, select Save As, give your document a new name, and click OK. You may even be able to use your word processor's macro command facility to partially automate this process.

Of course, if you're part of a large operation that has a formal document-management system for its word processing documents, it's an equally simple matter for your staff to spend a morning or afternoon mass-converting documents for your Intranet. After all, you're already organized to manage your word processing data.

Either way, once you've saved your files in ASCII format, you can create an HTML document containing a list of the converted documents as hyperlinks and get your Intranet off the ground with almost no difficult work.

If you do have Internet Assistant for Microsoft Word installed (available on the CD-ROM), then you will have an additional item in the Save As Type list of the Word Save As dialog; namely HTML Document. Of course, you would think that option would be exactly what you want; however, check the result carefully because some documents might not be automatically converted the way you would expect.

Retaining Document Formatting

Unfortunately, when you save word processing documents as plain text, you lose the benefit of some of the package's special formatting features. Text enhancements like boldface, underlining, italics, and font selections all disappear. What's left are perfectly readable lines of plain text, but you'd probably like to have some of the original document's formatting back.

Besides losing formatting, you may also lose some actual content from a document when you convert it to ASCII format. Tables suffer especially in saving a document as plain text-they seldom resemble their original form when converted. Graphics usually disappear altogether. As a result, even though you've made rapid strides in creating your Intranet, you'll want to take some additional steps with at least some of your documents to preserve the documents' integrity.

The Rich Text Format (RTF) was introduced in Chapter 3, "The Software Tools to Build a Web." As you'll recall, Microsoft developed RTF as a means of enabling portability of documents among different applications, including different word processing packages. The specifications for RTF were made public and most of Microsoft's competitors in the word processor market have added support for RTF to their products. Both WordPerfect and Word support RTF as one of the document formats available through the Save As dialog box.

In just a few minutes' time, a batch of Word documents can be converted into HTML by using Word's Save As feature to create intermediate .rtf files. The intermediate files can then be converted to HTML using the freeware rtftohtml package available on the CD-ROM included with this book.

If you want to populate your Intranet with useful documents as fast as you can click OK, all you need to do is save or copy the documents into the <Home> directory of the WWW Service and ensure that Directory Browsing is allowed and there is no file named default.htm. This procedure creates a quite unattractive, but useful, browser listing of all the documents you collect as you build your Intranet. The next step, of course, is to build a home page that contains links to and descriptions of each of the documents.

Adding Graphics

Adding graphics to your Intranet is just as easy as publishing other documents. Suppose you have various picture files lying around on your LAN in pcX or Windows BMP format (such as those created by Microsoft Paintbrush). Unfortunately, most Web browsers don't support direct viewing of .pcx or .bmp files without a helper application. Although helper application setup is quite simple in most browsers, and viewers for pcX files are widely available, you probably don't want to require all your customers to change their browser setup. A better idea is to convert the existing images into a format all Web browsers can read directly, such as .gif (Graphic Interchange Format) or .jpg (Joint Photographic Experts Group).

The Paint Shop Pro program included on the CD-ROM with this book is well-suited for the task of image conversions. You simply load the existing image, choose File | Save As, and select GIF- Compuserve in the List Files of Type drop-down list. Table 7.1 shows a list of dozens of typical image file formats that you may come across on your LAN. Paint Shop Pro (and other graphics programs available on the Internet) can handle many of these.

Other Legacy Data Conversions

In addition to your word processing documents, you no doubt have other kinds of information stored in electronic format. The following sections look at how some of this legacy data can be converted for your Intranet.

Spreadsheet Data Files

Chapter 14 explains how to create a data warehouse on your Intranet with live spreadsheet data files. Because you're in a hurry to get your Intranet off the ground, though, you can get some static information from your legacy spreadsheet files up and accessible right away. As with your word processor, your spreadsheet program probably has a Save As command that enables you to save data in plain text format. Both Microsoft Excel and Lotus 1-2-3 have such features.

Both Microsoft Excel and Lotus 1-2-3 use the default filename extension .txt for converted files as well. As with the word processing files, you should accept this default because the plain text MIME data type/subtype is directly supported by all Web servers and browsers. If you're using another spreadsheet package, check its documentation for a plain text Save feature. Such files are directly usable in your Intranet, so any tabular data you have in your legacy spreadsheet files can be made available on your Intranet as quickly and easily as your word processing files.

Miscellaneous Legacy Data Conversions

Most relational database packages have one means or another of saving tables of data to text files you can use on your Intranet. For example, Microsoft Access has an Output To function, which can save database tables not only to plain text but also to RTF. The latter capability is interesting in that you can run the resulting RTF file through the rtftohtm program (available on the CD-ROM that comes with this book) to convert your data to HTML. Other database packages have similar features, although you may need to design a simple database report and direct its output to a plain text file to get what you want. As a result, you can export data from almost any database application for viewing in your Intranet, again with relatively minimal effort.

Helper Applications for Your Customers

Helper applications are computer programs to which your Web browser can pass data that it cannot display directly by itself. This sort of data typically includes audio or video, but, as you'll learn in Chapter 12, "MIME and Helper Applications," almost anything can be supported by the correct helper application.

Because you might have legacy data in video or audio format or in image formats not directly supported by Web browsers, you should provide your users with some basic helper applications. (Chapter 12 explains how to set up a means of distributing helper applications and other software/data on your Intranet.) The following are a few you may want to obtain for your customers:

• Adobe Acrobat Reader
• Paint Shop Pro
• MPEGplay
• QuickTime

All these packages are either freeware or shareware, and the latest versions can easily be obtained on the Internet.

Adobe Acrobat Reader is a free, read-only application that can display PDF documents; you can't use it to create documents. You can retrieve the Acrobat Reader directly from Adobe's Web site at http://www.adobe.com/Acrobat/readstep.html, where versions are available for Windows, Macintosh, MS-DOS, and UNIX systems.

Helper Application Configuration in the Browser

Helper application setup is a subject that will be covered in a great deal of detail in later chapters. This section takes a quick look at this topic, using Netscape as an example, because you need to be able to test the documents and data that you are publishing on the Intranet.

Suppose you want a person browsing your page to be able to play a Windows Audio WAV recording of you welcoming them to your Web page. If the .wav file containing your welcome message is named welcome.wav, add the link with the <A> tag, just as you would add any other link on your page, as in the following line:

<A HREF="welcome.wav">Listen to our Welcome Message</A>

Of course, you can create a link to any type of file on your page, and when the person clicks the hyperlink, the file will be transported to the client application (Web browser) through HTTP. The key to all of this is that the Web browser on the receiving end of this link must be configured to handle the incoming file.

Most Web browsers are configured to handle *.htmL, *.htm, *.TXT, and *.gif files. These and other standard file types are given a MIME type. See the following sidebar for a basic discussion of MIME. For file types other than the basic ones mentioned, you just need to configure your Web browser to handle the MIME type of that associated file.

In addition to configuring your Web browser to be aware of the file type, you will also need an application capable of displaying or playing the file. For several types of multimedia files, you already have an application that can handle this job. Windows NT and Windows 95 include an application called Media Player, which can play AVI, MID, and WAV files. Just follow these steps to configure Netscape Navigator 2.0 to use Media Player:

1. Run Navigator and choose Options | General Preferences. Select the Helpers tab in the dialog box that appears. You will see a list of all the MIME types that Navigator is configured to handle.
2. Highlight the MIME type for audio/x-wav with the file extension .wav (see the right hand column). Select the Launch the Application radio button. (See Figure 7.9.)
3. Choose Browse and select MPLAY32.EXE. It should be in the Windows\System32 directory where you installed Windows NT.
4. Choose OK.

Netscape Navigator is now configured to launch Media Player any time you click a hyperlink to a file type of *.WAV. Now you can go through the same steps for *.AVI files.

Figure 7.9: Configuring Navigator MIME types.

Note that in Step 2 there are other options for the Action radio button. You don't have to configure Navigator to launch an application for every MIME file type. For example, when plain text files are received by Navigator through HTTP, you can choose View in Browser or Save to Disk. Netscape Navigator is set up by default to handle many more MIME types than the ones mentioned here, including *.AU and *.AIFF files for audio.

Summary

This chapter has focused on helping you get your Intranet up and running using data you already have on hand. The main benefit of this approach, which will be extended in later chapters, is to get your Intranet online as quickly as possible. As you've seen from this chapter, you can easily start your Intranet by using just a few tools off the CD-ROM and your existing data. This chapter covered how you can

• Configure the WWW Publishing Service in IIS.
• Evaluate the information your organization is already providing for possible inclusion on your Intranet.
• Focus on the information that is in electronic format.
• Convert your legacy data so it can be immediately usable on your Intranet.
• Configure common Web browser helper applications for viewing your data. Part III of this book will cover this subject much more extensively.

Chapter 12, "MIME and Helper Applications," delves more deeply into important details you will need to add value to your Intranet, including some basic information about how helper applications work. This information will help you extend the helper application paradigm in new directions for your Intranet's customers.