• Put your Intranet site on the Internet in an organized fashion - By controlling the process of moving your site to the Internet, you can ensure that the conversion flows as smoothly as possible and that the user's experience is a good one.

• Learn key performance indicators to monitor on your server - There are several key counters that you can monitor to understand how your server is handling requests. You'll see what these counters are and how best to display and monitor them.

• Use your Intranet over the Internet - Providing access to your Intranet over the Internet may provide key information to field offices, remote users, or others who may have access to your systems only from the Internet.

Introduction

This decision can be driven by many different things. First, there can be a compelling need to get information out to the people in your company, regardless of their geographical relationship to your offices. If you have salespeople who are on the road working with customers, you can use the Internet to provide them cost-effective access to your corporate systems.

Second, people need to know about your business, and in many cases, customers expect to see a URL on your business card just as they expect to see your mailing address and phone numbers. Being on the Web is almost a given in today's business community.

Being on the Internet can be dangerous if you don't do it correctly. If you take a chance and just wire your Internet connection directly into your internal network backbone, you'll be opening yourself up to misuse by anyone and everyone on the Internet. They'll be able to browse your computers, review the shares you may have established, and more.

Luckily, there are safety measures you can take. You should understand firewalls, segmented LANs, and the different technologies behind them so you can make an informed decision about the best protection for your needs.

There are three steps to take as you move to the Internet. These are tried-and-true, and I can attest to their value from personal experience.

1. Create your internal Intranet site. Bring up the server and test all aspects of the server locally.

2. Install the second network adapter for your system (as described later in this chapter) and assign your server an Internet IP address. Tell others in your company or circle of business friends of the address, and allow them to access the system.

3. Publish your Internet address with Internic and make it generally available.

Of course, for each of these three steps, there are several additional steps that you need to take. The purpose of this chapter is to provide you with a roadmap of sorts that takes you through the process of bringing up your server on the Internet in a controlled manner.

Step One: Bringing up your Intranet

If you do not yet have your Intranet in place, your should take care of that now before you continue with the rest of this process.

Step Two: Initial Internet Connectivity

When you set up your Intranet, you create your server on the network. You tell everyone your computer name and/or IP address, so they can start accessing your system. In some cases, depending on the type of network you're running and the size of your network, you may incorporate DNS name services on your LAN or WAN. In this type of environment, you're much like the Internet. The key difference is that, while you may not personally know each individual that your company employs, or who has access to your network, you do presumably know that they are employed or contracted by your firm and that they have business being on the network.

With the Internet, you simply don't have this luxury. Since you can't control who accesses your computer by limiting who is on the network, you must take a different approach and control what people can see on your network, limiting this vision by means of user authentication. Authentication can mean having the user provide a user name and password, or it can simply mean limiting the range of IP addresses that can see the server.

Internet IP Address Considerations

One of the first things you should do is to install a new network adapter in your system. This is true even if you'll be accessing the Internet over your standard LAN connection. The reason for this is that you'll be able to more closely control access over this card. As part of this first step, you should limit access to your server over the existing Intranet card to the IP address ranges that are known to be on your internal networks and not coming in from the Internet.

If your system is running on a network segment with access to the Internet, you can accomplish the same controls by creating a multi-homed server. Multi-homed servers allow you to establish more than one IP address for your system. You definitely need to set up multiple IPs for tracking and control purposes, so at the very least, you'll want to consider and understand the multi-home approach. When you multi-home your system, you can follow the steps in the rest of this section just as if you'd added a new network adapter. The advantage to using the multi-home approach is largely one of economics, as you won't have to purchase an additional network adapter. The disadvantage can come if you have your Intranet on different LAN segments or entirely different networks from each other. If this is the case, a multi-homed server simply won't suffice. You'll have to use multiple network cards. In short, if you're on a network with both Intranet and Internet access, you can use either the multi-home approach or the multi-adapter approach. If you're on a LAN that has been physically or logically segregated to separate Intranet and Internet access, you'll have to use the multiple-adapter approach. For more information about multi-homing your server, see "Setting up a Virtual, or Multi-Home Server" in Chapter 8, "Allowing Dynamic User Access."

To filter IP addresses, start the Internet Service Manager and double-click the WWW service entry for your server. Select the Advanced tab to indicate the ranges of allowed IP addresses. See Figure 15.1 for an example.

Figure 15.1 - The Advanced tab lets you indicate the IP addresses to allow or disallow access to your server.

First, select the Denied Access option, which indicates that, unless its IP address appears in the list below, a computer does not have access to this server. If you leave this option selected and no IP addresses indicated in the list, nobody will be able to access the server.

Next, select the Add button. You can either specify the IP addresses of individual computers or use wildcards to allow an entire range of IP addresses access to the server. See Figure 15.2.

Figure 15.2 - By specifying only the first portion of the IP address, you can create a wildcard IP address, allowing any computer access with an IP address in the range you indicate.

By completing this step, adding each address or range of addresses that you want to give access to, you provide yourself with some solid security to prevent unexpected access from the Internet.

Disabling IP Routing

To modify the option, select the Network application from the control panel. Select Protocols, TCP/IP Protocol and then click on Properties. Click the Routing tab to find the option. Figure 15.3 shows the single-option dialog box.

Figure 15.3 - Leaving the IP Routing option selected creates a bridge between networks.

Baseline Intranet Testing of your Server

In Chapter 11, "Building Databases for Intranet Access," in the "Logging IIS Accesses to ODBC Databases" section, you learned how to set up a database to log all accesses against your different services. Be sure you've set this up in some fashion before providing external access to your server. The information stored by these logs is valuable in helping track down and solve problems you may encounter from different access methods. Remember, not only can you not control WHO accesses your system, but you also have no control over HOW they access it. With the logging activated, you can track who is online, what services they're using, what pages, files, and directories they're accessing, and how much information is downloaded from your system. This is all very valuable information for management of content, access counts, and more.

One configuration you may consider is shown in Figure 15.4. In this configuration, several different values are being tracked for the different services that are running.

Figure 15.4 - By watching several key values in the performance monitor, you can keep an eye on the general state of your server as it begins to be accessed more and more.

The options that are key to monitoring your site include those in Table 15.1.

Table 15.11-Performance Monitor Key Indicators

Counter	Scaling Factor	Counter Object
FTP Current Connections	1.0	FTP Service
HTTP Current Connections	1.0	HTTP Service
FTP Total Bytes/Sec	0.001*	FTP Service
HTTP Total Bytes/Sec	0.001*	HTTP Service
% Usage, Page File	0.1*	Paging File
Not Found Errors	1.0	HTTP Service

* these values are not the default scaling factor - you'll need to modify them for your needs.

You'll also notice that the scaling on the graph has been changed to reflect values in the 1..10 range, compared with the 1..100 values shown by default. In the sample graph, the values for the Total Bytes/Sec counters have been scaled to this graph, using 0.001 for the counter multiplier instead of the default value.

The result is a graph that shows, in relative terms, the activity on your server at a glance. You'll know very quickly what the number of connections is. The reason for including the Page File Usage in the statistics is really twofold. First, if you notice the page file usage growing steadily, you'll want to check on the types of access being completed. If you have an ISAPI application running, it could be that you have a memory management issue, or possibly a problem in how connections are managed.

An increasing percentage of the paging file being used generally means that more virtual memory, the paging file, is being required as time goes on. This typically shows that you either need to track down a programming problem, or that, as more users access the server, additional resources are required to handle the load. In any case, if your Page File is above 80% you should consider increasing the size of the file for performance considerations. If it continues to require additional resources, and you're certain you don't have a resource problem with a program, you should consider adding more memory to the system. It could simply be that caching pages to serve user requests is taking up a significant portion of the system resources.

One final counter that you may want to add is the % Processor Time on the Processor object. This is the default counter that comes up when you decide to add a counter to the graph. This counter is a great gauge of how busy your system really is. For example, you'll notice that if you're using FrontPage, and you have several people working on authoring pages, processor time peaks when they are interactively creating and saving pages to their respective Webs. This can impact other users and may have an influence on the extent of access you'll be giving for FrontPage users.

Limited Access to Your Server for Internet Testing

If you have external users that are receiving their IP address dynamically, as is often the case with people using a dial-up account from an Internet Service Provider (ISP), you can determine at least their base address by asking them to log in to their service and then select Start, Run and enter WINIPCFG. As you can see in Figure 15.5, the result is a dialog box that indicates the IP address that was assigned to their system.

Figure 15.5 - Using WINIPCFG, you can quickly determine assigned network addresses.

In Figure 15.5, an IP address of 198.68.42.72 has been assigned with a subnet mask of 255.255.255.0. It's likely that the IP address that will be assigned to this computer will have at least the first two values, if not the first three, of the assigned address. You can verify this by asking the user to sign in a few different times and check the IP address after each sign-in. If this address base remains the same, simply set up the entry on the Advanced tab so that the address root of 198.68.42.0 is allowed, giving all addresses with that starting value access to your site.

Next, tell the user the address of your site. This is the Internet address assigned to your system. For example, if the site is at 200.200.200.5, this is the value that the test users can use to access your system. To do so, they simply indicate a URL of http://200.200.200.5 in their browser. This loads the default page, if you've set one up, and they can begin testing your system.

If you're not using the default page option, be sure that the incoming users specify your home page in the URL. If they don't, they receive an error message indicating that they don't have access to your system.

Some things to look for in your limited testing group are:

• Browser types - get as many different types as possible to access your site. In addition, have people access your site from different "brands" of browsers. For example, the browser the CompuServe uses, a type of Mosaic browser, may behave differently or experience different results compared with a Mosaic browser obtained elsewhere.

• Look for different Internet access speeds. This helps you ensure that your site is as acceptable at 14.4 as it is at 28.8 and above.

• Get as many different levels of users as possible. Will they understand your layout? Does the site make sense and is it easily traversed?

• Get as many people as you can, and load the server as much as possible. Many administrators unwisely overlook load testing until it becomes a crisis. Test your server out now, in advance of the real loading that's sure to come from your customers.

As you test each of these groups of users, make a note of the load your system experiences. This helps give you some idea of what to expect as more and more people begin accessing your system. When you put your system on the Internet, you'll quickly see that loading of the server is a bit less strenuous on the system. This is because that Internet serves as a bit of a bottleneck for the requesting user. The speed at which users are accessing your system depends on a great many things, not the least of which are:

• The speed of their modem

• The speed of their ISP's modems

• The speed of their ISP's connection to the Internet

• The overall loading of the Internet between their access point and your Web server.

These speed restrictions are both good and bad for your site. They're bad because they impact the users' experience on your system. They are apparent in overall response times to load and display pages.

The good side is that, since the workstations accessing the server generally can't use the information as quickly as it can be provided, it allows your server to do other things while serving requests to the client systems. At the highest, most general level, this means that the server can support more Internet users than Intranet users, as Intranet users generally have high-speed, high-bandwidth access to the server.

Virtual Servers

Figure 15.6 - Virtual Servers give you a good migration path from your Intranet to the Internet.

As a starting point to migrating to the Internet, consider establishing a Virtual Server with a different Web for its home page. Set up this home page so it's a simple, single-function page that merely provides a message to anyone accessing it that they've reached your site. The point of this page is only to confirm a connection to your server.

Leave the original IP address pointing to your original Intranet. At this point, you don't yet have your Intranet on the Internet-only a temporary page is on the Internet.

Next, start copying the information from your Intranet to the Internet site. Do so one page at a time after you confirm the content of each page. You should also take the time to access the site from the Internet and make sure the links are valid and the pages are accessible outside your network.

If you code URLs in your Intranet Web pages with an absolute address, such as http://netserver1/mydocs/newfile.htm, you may experience problems accessing the pages from the Internet. This is because there is no concept of "netserver1" on the Internet so the name can't be resolved. To avoid this problem, you should code your hyperlinks with relative URLs, such as http://../mydocs/newfile.htm. If you do, when the reader accesses the page, the correct URL, whether it be an Internet name or Intranet name, is substituted to make the URL fully qualified. You won't have to change anything to keep the link active on the current Virtual Server.

Here is one final idea about using Virtual Servers. You can use them as switching mechanisms once you determine that your site is ready for prime-time. For example, assume you've set up the server to support the different home directories as described here. Once you've decided to move the Intranet content to the Internet, you can simply update the Internet Home directory so it points to the same starting point as the Intranet site. This way, regardless of how people are accessing your site, they'll be coming into the same point on the Web site. See Figure 15.7 for an example.

Figure 15.7 - Mapping two or more Virtual Servers to the same home directory is a final step in migrating to a shared Intranet and Internet site.

If you are using FrontPage, be sure to read the section later in this chapter regarding the considerations for using FrontPage prior to mapping the directories to a common Home location.

Sharing Content

Figure 15.8 - By pointing a home directory to an area within the Intranet Web space, you can create a virtual sub-Web.

As another way of looking at this, consider Figure 15.9. You can see that your Intranet site may be all-encompassing, and that you can establish several sub-web sites that provide different access points into your system.

Figure 15.9 - You can use Virtual Servers to organize the concepts behind your web, making it easier for customers to understand the Web's organization.

FrontPage Considerations

This is because, if you uninstall the extensions against one of the Virtual servers, you'll actually uninstall both. While FrontPage will show the remaining server as having installed server extensions, you won't be able to uninstall successfully from that server. You will also have trouble re-installing to any other server on that Home directory.

You can save all problems with FrontPage by either uninstalling the extensions against Virtual servers prior to modifying their Home directories, or by waiting to install the extensions until you've set up the permanent Home directories.

Giving Intranet Access from the Internet

This may seem strange at first, but since you're expanding the scope of your Intranet, you have the option of doing so by using a little-used feature of Windows. Windows supports a workstation-based name resolution utility that references a file on the local hard drive to determine IP addresses. The file, LMHOSTS, resides in the Windows subdirectory for Windows 95 and in the <windows>\system32\drivers\etc directory for Windows NT.

The file is a simple text file that indicates a mapping between IP addresses and their friendly names.

xxx.xxx.xxx.xxx netserver1 #pre #DOM:intellicenter
xxx.xxx.xxx.xxx system_1 #pre #DOM:intellicenter

Names can also be of the format www.intellicenter.com. Any valid computer name will work.

If you distribute this file to the sites that will be accessing your Intranet server over the Internet, you can give them instant access to your system. In the case of the mappings shown earlier, a URL of http://netserver1 would map to the server you indicate the IP address for. This makes it much easier for users to use your server. More information about the LMHOSTS file appears in the sample file, LMHOSTS.SAM, included on your system, and you can find additional information in Chapter 2 in the WINS installation and configuration options sections.

Reality Check

The issues with FrontPage and multi-homed servers came up several times in working with the different home directories, and re-installing FrontPage seemed to be the only way to overcome the issue once you've uninstalled one of two copies mapped to a common Home location. Future installations avoided this by installing the extensions only once against a given directory structure.

The LMHOSTS file was used to grant more exclusive access to the system. By giving students a "key disk" with the LMHOSTS file included, we were able to give the students a different entry point into the server and to provide a different service to the users. This mixed a private Web site with the public one, controlling access by controlling knowledge of the site's address. Of course, since the site is on the Internet, we still password confidential materials, but initial access was made easier using the LMHOSTS file.

At Integra, another reality check site, when the site was opened to downloads of software, there was a concern regarding bandwidth to the server from the Internet. We wanted to provide a mechanism for downloading multi-megabyte files from the server for evaluation by the potential customer. To solve the bandwidth problem, we created the base services on the internal server, those of getting the user name and address information, and then stored the actual download files on a third party ISP system that had fast access and high-bandwidth to the Internet.

Using this technique, we were able to gain the information about the people who were downloading the applications, but at the same time we weren't in a position of saturating incoming Internet bandwidth.

From Here...

• Chapter 14 details the use of FrontPage to manage sites. This application can prove to be a good partner in the production of the content for your site.

• Chapter 2 explains about accessing other sites using LMHOSTS and some of the options for using this feature.

• Running a Perfect Web Site from Que Corporation explains some more pointers about how you can best bring up and maintain a web site on the Internet.

Copyright ©1996, Que Corporation. All rights reserved. No part of this book may be used or reproduced in any form or by any means, or stored in a database or retrieval system without prior written permission of the publisher except in the case of brief quotations embodied in critical articles and reviews. Making copies of any part of this book for any purpose other than your own personal use is a violation of United States copyright laws. For information, address Que Corporation, 201 West 103^rd Street, Indianapolis, IN 46290.

Notice: This material is from BackOffice Intranet Kit, ISBN: 0-7897-0848-5. The electronic version of this material has not been through the final proof reading stage that the book goes through before being published in printed form. Some errors may exist here that are corrected before the book is published. This material is provided "as is" without any warranty of any kind.