An Intranet Checklist

Introduction

Intranets require TCP/IP networking protocols. Upon this foundation, the core intranet technologies reside. In this paper, we will show that all intranets, regardless of their application, share commonalities. We will review these commonalities, explore several optional components and develop a checklist for use in building an intranet from a common file-, print- and directory-service LAN.

Common Features of Intranets

1. A LAN Using the TCP/IP Networking Protocols
2. One or More Web Servers
3. A Web Browser for each Client
4. Electronic Documents or Reports to Share
5. Electronic Mail Services

In an intranet, people have many ways to communicate. They communicate with each other by electronic mail and perhaps by news groups or conferencing systems. They make information available to groups of people with departmental Web servers. They share information. These building blocks are sufficient to set up an simple intranet. As we will see in the following section, though, the addition of a few more pieces will provide a much more useful system.

a) A LAN Using the TCP/IP Networking Protocols

Even Novell NetWare users can build an intranet, but they do it by using newly-bundled TCP/IP capabilities of NetWare 4.X, not the older NetWare protocols. See Novell's Web Tour [HREF 2]

b) One or More Web Servers

The Web is the progeny of decades of research is distributed computing. When the Web first became available, people of all walks of life, from the Vatican to a 12-year-old in Oakland, set up a Web server. Corporate Boards met a year later to determine an Internet policy, only to find that they already had hundreds of Web servers operating. That's the power, and the difficulty, of distributed computing.

This kind of distribution is powerful because many hands make light work. Many individuals make data available to an even larger audience. If the work is centralised, it becomes someone's full time job. The down side is the lack of a centralised way to find things in this distributed world. On an intranet, this can be handled by mandate, guidelines, brute-force search, or a combination of these methods. These options are discussed in more detail in Section IV, Navigation of Intranets.

c) A Web Browser for each Client

• Cost of the browsers (some are free).
  If you are building an intranet in an academic environment, you have your choice of many browsers at no cost. If you are in a corporate setting, cost may be an issue. You may choose to use the free version of Mosaic from NCSA [HREF3] or to download trial copies of software for an intranet pilot project prior purchasing browsers.
• Support for standard or proprietary HTML extensions.
  If you choose to use uncommon HTML extensions (e.g. Microsoft's or Netscape's), ensure that the browser that you choose will handle them properly.
• Additional features of the browsers (e.g. electronic mail).
  If you choose to integrate Internet-style electronic mail into your intranet, you may choose to use a browser package that includes e-mail capabilities. The same can be said for other features that are rapidly becoming available: Conferencing, integration with a particular database, etc. Performing a single installation of software on each machine can dramatically reduce the time and cost of an intranet rollout.

d) Electronic Documents or Reports to Share

The form of your data determines the architecture, hardware and server demands of your intranet.

e) Electronic Mail Services

E-mail is responsible for the vast majority of person-to-person communications on the Internet. It is asynchronous, taking place at the convenience of both the sending and the receiving parties. It is rapid, barring a poor network architecture. It is private, falling victum to hackers at a rate well below statically-stored data.

On an intranet, electronic mail provides individuals the means of communicating directly with each other on a topic of timely interest, including only those who need to be involved.

So what?, you may ask. Every LAN comes standard with some type of electronic mail, and has for many years. Why should we get rid of Microsoft Mail just to get an intranet? It works for us! The answer is simple: TCP/IP-based mail, known as SMTP with MIME, for Simple Mail Transfer Protocol with Multipart Internet Mail Extensions, provides an open and scalable mail solution that includes multimedia capability. By switching to Internet mail standards, your LAN can grow more easily, with less systems administration, and take advantage of a wide range of mail attachments (documents, spreadheets, graphics, etc), without the hassles of trying to force them through a gateway. In short, if you have any plans to connect your LAN to the Internet, now or in the future, Internet mail is for you.

Additionally, if you choose to use Netscape Navigator [HREF4] as your Web browser (as most have done), your client desktops will already have the necessary Internet mail client software. All that is missing is the server, which can be procurred as part of a PC TCP/IP package, as freeware or as part of a seperate commercial offering, such as Netscape Mail Server [HREF5].

Optional Intranet Components

1. One or More Databases (preferred)
2. Search Engine (preferred)
3. ftp Server and Archive
4. Mailing Lists
5. Network-Aware Applications
6. Connection to the Internet
7. Connections for Teleworkers
8. Management System

a) One or More Databases (preferred)

In the case that Web-enabled interfaces to your particular type of database exist, or you have the ability to code them, documents may be generated dynamically from records in the database. In this way, the information is always correct up-to-the-minute.

Much software exists to interface relational databases to the Web. Large database companies such as Oracle [HREF6] have commercial products to provide such an interface. Oracle even provides an (optional) Web server and proprietary client to work with the product. Many programming and scripting languages also provide a mechanism for interfacing to such databases.

Much of today's corporate data in held in large legacy databases, such as IBM's DB2 [HREF7]. IBM and others have begun to ship tools to ease the pain of getting this informtion to the Web. The other alternative is to create the code yourself. This is often not as difficult as it sounds. Most databases can print periodic reports to a file instead of a printer. These files can be formatted as you see fit. Formatting these files in HTML is often a trivial task and allows them to be placed in public view by a Web server.

b) Search Engine (preferred)

Several free search engines are available, such as Excite for Web Servers [HREF8] from Excite, Inc. or the Harvest System [HREF9] from the University of Colorado at Boulder. They are powerful and efficient, but take some understanding of UNIX systems administration to properly operate.

Commercial products are also becoming available to perform this function. Netscape's Enterprise Server, for example, includes search capability in the Web Server itself.

c) ftp Server and Archive

An ftp archive can be linked to Web documents since most Web browsers understand the ftp protocol. There is no need for the user to see more than one software package.

d) Mailing Lists

By use of a series of mailing lists, automatically or manually generated messages can be sent to a group of people every time their attention should be drawn to Web-based information. For example, let's say that the Human Resources Department has changed the employee handbook. A mail message sent to all employees would inform them to review the changes. Electronic mail works hand in hand with Web services.

e) Network-Aware Applications

f) Connection to the Internet

Many organisations wish to have an Internet World Wide Web presence. Most intranet managers wish to share only a small fraction of their intranet data with the public at large. Still, after building an intranet, that subset of information will already by in a form suitable for Web servers. It is an easy step to copy that subset to a public Web server.

If your intranet architecture included Internet-style electronic mail instead of more traditional LAN-based mail, providing Internet mail to your users will be straight forward. It is simply a matter of connecting to the Internet and routing the mail to your existing mail server.

If you plan an Internet connection, think ahead. Every TCP/IP LAN requires that each machine have a unique number, called an IP address. Ensure that you register a block of these numbers with the local Internet Network Information Center and use only those numbers for your machines. While it is possible to use any IP addresses you choose on a LAN unconnected from the Internet, when you choose to connect, they will all have to change. This is far to large a task for most organisations to do more than once.

For those granting complete Internet access to users on their LAN, security becomes a major concern. While all of the problems have been solved, protecting your LAN requires an expertise in these solutions.

g) Connections for Teleworkers

With an intranet, all of the tools are in place except one. How will your remote users connect to the network? If you have Internet access, they can reach the network that way. If not, you may wish to install one or more modems on a terminal server to allow dial-in access.

In either case, ensure that all necessary security precautions are strictly adhered to. In the case of an Internet connection to a LAN, a firewall is absolutely essential. In the case of a terminal server, do not publish the telephone numbers to anyone except those allowed access and enforce a good password policy. Monitoring your network for signs of intrusion is a good idea whenever outside access is permitted.

h) Management System

In the smallest of intranets, documents may be updated by hand each time a change is required. That means that one or more people will spend a lot of time making certain that it all works properly. As the intranet grows, this task will become more and more daunting, until it requires a more professional approach.

In all but the most centralised intranets, multiple individuals are responsible for providing data to the system. Not all of them will be familiar with HTML, or need to be. Software such as Netscape's LiveWire and LiveWire Pro [HREF11] can check for accuracy of a Web system and Plugged In's HTML Remote [HREF12] allows creation or update of Web documents by electronic mail, without the need to know HTML.

Navigation of Intranets

An intranet generally has one of the following three types of navigational structures: mandated, guidelined or searched. Any combination may exist. This section is intended as a guide to help you choose the method that is right for you.

Mandated navigational structures are organised from the top down. A central authority defines where documents will go in each organisation, defines a naming convention for the documents and a directory structure to use to get to them. This approach becomes unwieldy in large organisations, however, it has its uses. It is normally found in intranets which only operate one Web server, with one person responsible for it all.

Every intranet should have a 'home page' which points to each major resource on the system. This provides a starting point for new users and those who get lost. This page should point to all departments, whether they operate their own Web servers, or share part of one. Since this page should be managed by a single individual, it is likely to be managed by mandate.

A guidelined navigational structure is on in which the central authority outlines a structure for the entire organisation at a high level, but leaves the individual departments to put pointers to their own data, in their own structure.

Searched navigational structures employ a search engine to get around the problems of direct navigation. This method is extremely valuable, but because of the computational resources used in constant searching and the need for a more intuitive mechanism, it should be used in conjunction with one of the other methods.

Most intranets operate as either mandated or guidelined structures and include a search engine as an alternative means of finding data.

Sample Intranet Architectures

a) A Small TCP/IP Network at Plugged In Communications (Internet Connected)

b) A Medium-Sized Novell Network (Without an Internet Connection)

c) A Large TCP/IP Network at Lawrence Livermore National Laboratory (Internet Connected)

An Intranet Checklist

1. Define a Network Architecture

• Which services will you install?
  • Web access to static documents
  • Web access to dynamic documents
  • Web access to database(s)
  • Internet-style electronic mail
  • Search engine
  • ftp server
  • Network-aware applications
  • Mailing lists
• Which machines will act as servers?
• Which machines will act as clients?
• What will your connections be to the outside world?
  • Will you provide public information to the Internet?
  • Will your users have Internet e-mail?
  • Will your users have full Internet access?
  • Will you support teleworkers?

2. Run the TCP/IP Networking Protocols on your LAN

• Assign an IP address to each machine
  • If you ever plan on connecting to the Internet, register and use a block of Internet IP addresses.
• Choose a TCP/IP stack for each client machine (e.g. NetManage Chameleon [HREF13] for Windows PCs, MacTCP for Macintoshes)

3. Configure One or More Web Servers

• Choose a server platform (e.g. Sun [HREF14] workstation/Solaris or PC/Windows NT)
• Choose a Web server (e.g. NCSA Web Server, Microsoft Internet Information Server or Netscape Enterprise Server)
• Install the Web server(s)
• Choose a location for static HTML documents
• Will you be writing cgi scripts for dynamic documents?
  • Choose a programming or scripting language (e.g. perl or tcl)
• Will you be accessing a database?
  • Determine the type of database
  • Will you be using a Web-database interface program?
    • Install and configure the package
    • Write procedures as necessary
  • Will you be programming an interface to the database(s)?
    • Choose a language (e.g. ora-perl, sy-perl, Java)
    • Code the interface

4. Install A Web Browser for Each Client

• Choose a Web browser (e.g. NCSA Mosaic, Netscape Navigator)
• Install the browsers on each client machine
• Don't forget to train the users!

5. Determine Electronic Documents or Reports to Share

• Determine a corporate policy defining public documents and those that must be protected (e.g. restricted to those who have a need to know and have signed a non-disclosure agreement)
• Separate documents as necessary into public and protected groups
• Configure your Web server to ask for a password before sending a protected document.
• Determine the mechanism for each type of document - some will be static (unchanging), some dynamically generated by a program and some from a database. Ensure that each of these documents can be served properly under your architecture.

6. Electronic Mail Services

• Will you be using LAN-based e-mail?
  • Will you be sending automatically-generated mail messages from your database or Web server?
    • Install an SMTP gateway to your mail system
• Will you be using Internet-style e-mail?
  • Choose a mail server (e.g. UNIX sendmail, Netscape Mail Server)
  • Install the mail server and set up user accounts
  • Choose a mail software for users (e.g. Chameleon Mail, Netscape Navigator)

7. Will you be using a search engine?

• Choose a search engine (e.g. Harvest, Excite)
• Install the search engine
• Ensure that your Web pages have a pointers to the search engine interface

8. Will you be using an ftp server?

• Choose an ftp server (e.g. Chameleon ftps, WU's ftpd)
• Install the ftp server
• Provide pointers from your Web pages to the ftp archive

9. Will you be using mailing lists?

• Determine the names and use for each mailing list
• Configure a mailing list server (e.g. listserv or majordomo)
• Update your Web site to include details on the use of each mailing list.

10. Will you be using more network-aware applications?

• Determine which applications suit your needs
• Install them
• Update your Web site to include instructions on their use.

11. Will you be connecting to the Internet?

• If no one in your organisation is familiar with connecting a LAN to the Internet, hire a consultant
• Register an Internet domain name, if you have not already done so
• If you have been using non-Internet-registered IP addresses on your network, remedy this
• Establish an Internet connection
• Will you have a public Web server?
  • If possible, make your public data a subset of you intranet Web server. Then you only have to mirror that subset routinely. There is rarely a reason to update the same data in two different places.
  • Generally, install your public Web server outside of the firewall. Everything that is on this machine is forfeit and effectively in the public domain.
• Will your users have access to the Internet?
  • Write an Internet security policy for firewall access
  • Train your users on the security policy
  • Build a firewall (this is not optional!)
  • Route incoming mail to your mail server
  • Monitor the network for security breaches

12. Will you be providing connections for teleworkers?

• How will the workers connect to your network?
  • If via the Internet...
    • Establish an Internet connection
    • Write an Internet security policy for firewall access
    • Build a firewall (this is not optional!)
  • If access is via direct-dial...
    • Install a terminal server and modems
    • Do not advertise the telephone numbers of the modems
    • Write a security policy for terminal server access
• Monitor the network for security breaches

13. Choose a management system

• Even if your intranet is very small and managed by an individual, define the tools that you will be using to maintain the site. For example, you may choose a text editor and an ftp client to upload the files, or Netscape Navigator Gold.
• For a larger site, you may wish to evaluate the tools available. If your site is built around an Oracle database, for example, review the cost and applicability of Oracle Web Agent [HREF15]. If you use a Netscape server, review LiveWire and LiveWire Pro.

14. Choose a navigation style

• If your intranet is very small and only one person will manage it, use a centralised, mandated directory structure.
• If your intranet is larger, develop guidelines for enterprise-wide navigation structures and determine the appropriate structure for individual departments. Ensure that Each department registers its resources with a central coordinator for inclusion on the home page.
• If you included a search engine in (7), above, ensure that all departmental coordinators provide pointers to it.

14. Don't forget to train the users!

Summary

The closer you are to a TCP/IP based network, the closer you are to an intranet, and to the Internet, as well. The world of TCP/IP networking is a robust, stable, effective way to communicate with others. The buzz word 'intranet' is simply the latest way of describing this fact. Luckily for those who took other paths to LAN networking in the past, networking technology is converging on the TCP/IP protocol suite.

There are many applications that run on the TCP/IP platform, but two are key to intranets - Web servers and clients and Internet-style electronic mail. These two applications give a LAN the ability to get information to everyone in an organisation and a to communicate interpersonally.

By following the checklist given here, any organisation should be able to plot their own course to an intranet, and out to the wider world.

Hypertext References

HREF1

http://www.plugged.net.au/dwood/ - David Wood's Home Page.

HREF2

http://www.netpub.com/cgi-bin/webtour/Tourist/1 - Novell's Web Tour.

HREF3

http://hoohoo.ncsa.uiuc.edu - National Center for Supercomputing Applications - Mosaic World Wide Web Browser.

HREF4

http://home.netscape.com/comprod/products/navigator/index.html - Netscape Navigator.

HREF5

http://home.netscape.com/comprod/server_central/product/mail/index.html - Netscape Mail Server.

HREF6

http://www.oracle.com - Oracle's Home Page.

HREF7

http://www.software.ibm.com/data/db2/ - International Business Machines - DB2 Product Brief.

HREF8

http://www.excite.com/ - Excite, Inc's Home Page and Excite for Web Servers Product Brief.

HREF9

http://harvest.cs.colorado.edu/ - Harvest System from the University of Colorado at Boulder.

HREF10

http://www.plugged.net.au/products/i_suite.html - Plugged In Communication' Intranet Suite Product Brief.

HREF11

http://home.netscape.com/comprod/products/tools/livewire_datasheet.html - Netscape Communications Corporation's LiveWire and LiveWire Pro Product Brief.

HREF12

http://www.plugged.net.au/products/html_b-e.html - Plugged In Communications'HTML Remote Product Brief.

HREF13

http://www.netmanage.com/ - NetManage, Inc's Home Page.

HREF14

http://www.sun.com/ - Sun Microsystem's Home Page.

HREF15

http://www.oracle.com/products/websystem/html/webSystemOverview.html - Oracle Corporation's Web Agent Product Brief.

Copyright