08 - Allowing Dynamic User Access

Give Users The Ability To Create Their Own Web Pages - By allowing people to set up their own web pages, you'll gain the confidence and interest of the different people accessing your site. Learn how you can provide "home pages" to the people on your system.
See how to provide FTP access to your site - IIS contains several different features that make bringing FTP to your site a real possibility. See how you can use some of the lesser-known features to allow your users to move to the next level on your system, providing content and updating their own objects.
Learn about different things you can do to test your site - Beyond the basics of testing your pages for being accessible, you'll need to take into account many different variables depending on your setting up your pages. Everything from database access to security concerns should be tested before you release your pages into production.
Learn how to set up virtual or multi-home servers and learn what this means for your site - IS supports the use of a multi-home environment, letting you set up more than one domain name and IP address that is serviced by the server software. Learn why you might want to consider using this technology on your Intranet sites.
You'll see how to monitor your site to make sure you keep your service level up and continue to accommodate increasing user demand and use of your system. - With so many things to offer on your Intranet, it will be important to be on top of the amount of activity your server is responding to. By putting into place appropriate tools and monitoring configurations, you can begin to track your system activity and start working to make sure it continues to be a responsive resource for your company.

Now that you've most likely implemented the basic underpinnings of your site, it's time to consider making it more open, more accessible to the users of your networks. Once the site is installed, and any security necessary is applied, you may find that allowing your user base to contribute is one of the fastest ways to add content and gain user-acceptance of the system.

By allowing users to create content to post to your system, you give the system a life of its own. As more and more information is posted, you'll find pockets of expertise that are available within your company, and you'll find that, when combined with other key technology components like Exchange Server and SQL Server, IIS can provide a very nice finishing touch to sharing information effortlessly to the desktop for your organization.

In this chapter, you'll see how to provide this access to your users, and how you can begin to fulfill some of the more traditional benefits of a "Web" environment for your company.

Becoming a "Service Provider" For Your Users

First of all, it's important to understand what the term "Service Provider" really means. Relative to the Internet, a Service Provider is typically a company that provides you with access to the Internet. The Service Provider, or SP or ISP (Internet Service Provider), has high-speed lines coming in to their business. They then split up these lines as appropriate for their user base. Typically, the user base for an established provider consists of a wide array of dial-up users. There may be a number of leased line or higher-speed connection customers, ranging in speed from 56k lines to T1 or greater.

In addition to simple access to the Internet, SPs typically also provide their customer base with a minimal amount of disk space that can be used for their home pages and a few downloadable materials if needed. This home page, and the maintenance of it, is the responsibility of the customer, but is provided for by the SP. The SP will issue the customer an address that can be used to access the customer's protected files. For example, the following URL indicates that, at least typically, a user named "SWYNK" has a home page URL on the IntelliCenter server:

http://www.intellicenter.com/~swynk

The tilde "~" before the user name simply indicates, by convention, that the space is part of the user's allocated space. In some systems, there is no tilde. It corresponds largely to naming conventions imposed by the SP. This URL points the browser to the default document located in the directory indicated.

Remember, if you have disabled default documents as defined in the properties for the WWW service, no document would be returned, if the user indicated the address above. There would only be an error indicating that the requested object could not be found.
You'll save yourself a lot of headaches by first instituting the default document, and, second, informing your user of the name of the document and the fact that it's the required starting point. Also note that, if you have users familiar with another Web server environment, they may be used to starting their site with a file named INDEX.HTML. If so, that may be what they're expecting to be the starting document here. Unless you change the default document name, you'll need to make sure that the users are aware of the difference.
Note, too, that you cannot change the default name for only a single user's access to the Web server, only for the system as a whole. If you do decide to change to a different default document, be sure to do it early in the process of bringing up your site, and be sure to notify your user community of the file name you select.

Becoming an SP generally means providing Web and FTP inbound access, as well as the typical download capabilities. It also means providing some security for the information that is maintained by a given user. In other words, you have some responsibility to prevent other users from changing any information besides that which they have provided directly. It would not be good to offer such open access only to find out that people are altering or altogether removing information made available by their peers.

A note of caution is in order with respect to allowing your user base to create and post pages. One of the all-time favorite bits of content to post on a personal Web page is a person's resume. If not the resume, certainly the person's name and credentials are sure to be a key topic on your site.
At first this seems great! You'll increase communications between different people, between departments and, in fact, company-wide. Beware, though, that if you are offering simultaneous outside access, in other words a connection to the Internet, you're also providing a really wonderful source for outside people to know some very juicy details about your company and the people that comprise it.
At the very least, you're possibly exposing semi-sensitive information to outsiders. But perhaps one of the biggest concerns is that you're also posting a who's who of your company, providing job seekers and employee seekers alike a wonderful stomping ground for rummaging through your company's key individuals. It's happened many times where a company roster is published and an outside recruiter uses this information to find all the right people to talk with. This may seem borderline paranoid, but is worth the thought that goes into securing your site. At the very least, you'll want to educate your users about what types of information should not be posted.

Creating a tree of users and their pages

One of the first things you'll want to do is to give people a place to start their own pages and content. Perhaps the easiest way to do this is to start a new virtual directory to store these pages in. First, create a USERS directory. This must be on an NTFS partitioned drive to be effective in controlling the access you are about to grant to users. Next, assign permissions to the directory such that only the system administrators can change objects, but the group EVERYONE has read-only access. This will be the starting security level for anyone accessing these pages. Figure 8.1 shows an example of setting this up.

Figure 8.1 - Be sure to reset the group Everyone so that it has read-only access to the directory tree.

By applying the permissions when you initially create the USERS subdirectory, you'll make it so that all of the different users directories you'll create will automatically have these rights. This is because when you create a new directory, it inherits the rights from its parent directory.
If you apply the rights after the fact, be sure to check the Replace Permissions on Subdirectories and Replace Permissions on Existing Files options. This will make sure the security model you create is applied to all content in the directory structure.

The next step will need to correspond with creating your users that you'll be granting this level of access to. For each user, you must set up a User Account, and you must grant them appropriate additional rights to his directory areas. Typically, for a user that you are giving this level of access, you'll be granting Full Control level access, allowing the ability to make new directories under the "root" directory, add and delete files, etc. See Figure 8.2.

Figure 8.2 - Be sure to grant the user specific, complete rights to his or her directory. This will allow him to create and manage the content he will provide.

Be extra careful assigning the rights to the directories. Specifically, make sure you assign the open access only to the user's directory tree. Otherwise, you may end up authorizing the user access to any directory in the Users directory tree.

Once you've assigned these rights, you'll have provided a way for people to put their own content on the server, while at the same time preventing other users from accessing it. When the user needs to upload items to the site, he needs to use a dedicated FTP client. When he does, he can log on to the site, indicate a userID and password, and send and receive files in this directory. The user will also be able to browse other people's directories, but will not be able to make any changes or additions to any site but his own.

As of this writing, you'll need to be using a dedicated FTP client to access these protected sites for uploading. This is because there is not yet a convenient way to provide authentication information - user ID, password, etc., - when you access a site with the FTP protocol.
You should expect this to change very soon, perhaps even by the time this book is published. As Web browsers become more intelligent, they'll also be able to handle the authentication of users, will work better with network security, and will natively handle uploads to a site. There are some instances already where partial support for uploading is provided, although the support offered is rudimentary at best, providing upload to generic, unprotected sites.
As Intranets become more and more prevalent, browsers will need to integrate with the network security on an overall basis, allowing the browser to use network login information to authenticate the user. This is already the case with a majority of other applications on the market, a fact that means you don't have to login multiple times to different applications.
Windows 95 and all version of Windows NT Workstation and Windows NT Server include command line FTP clients. These work great for testing your setup as they are extremely simple and provide a no-frills access to the site. Type FTP at the command line to start the application. There are a few key commands that you can use to quickly gain access to the site.

Table 8.1 - Windows Commandline FTP Command Basics
Open Establishes a connection to the server. Syntax: Open <site> -- where <site> is full site name, e.g., "OPEN ftp.intellicenter.com" to open the Reality Check site. When you login, you'll be prompted for the UserID to use. You'll also be prompted for the password for the user, if one is required. To logon to a site anonymously, use a user name of ANONYMOUS. See Figure 8.3 for an example.

Close Closes the current connection to the FTP site.

Get system. Gets a file from the site, downloading it to your

Put Sends, or uploads, a file to the remote system. You must have sufficient rights to do this.

CD <dir> Changes to a directory, as with DOS, <dir> can be any valid directory name relative to the current path. Note that backslashes in DOS, as in "C:\MYDIR," are represented as forward slashes, "/" on FTP on UNIX systems. Both the forward and backward slashes are supported with IIS's FTP Server. Also, remember that the FTP root directory, though specified as "/", really starts wherever the FTP home directory has been established.

Bye Exits the FTP client application.

Table 8.1 - Windows Commandline FTP Command Basics
Open	Establishes a connection to the server. Syntax: Open <site> -- where <site> is full site name, e.g., "OPEN ftp.intellicenter.com" to open the Reality Check site. When you login, you'll be prompted for the UserID to use. You'll also be prompted for the password for the user, if one is required. To logon to a site anonymously, use a user name of ANONYMOUS. See Figure 8.3 for an example.
Close	Closes the current connection to the FTP site.
Get system.	Gets a file from the site, downloading it to your
Put	Sends, or uploads, a file to the remote system. You must have sufficient rights to do this.
CD <dir>	Changes to a directory, as with DOS, <dir> can be any valid directory name relative to the current path. Note that backslashes in DOS, as in "C:\MYDIR," are represented as forward slashes, "/" on FTP on UNIX systems. Both the forward and backward slashes are supported with IIS's FTP Server. Also, remember that the FTP root directory, though specified as "/", really starts wherever the FTP home directory has been established.
Bye	Exits the FTP client application.

Figure 8.3 - The standard Windows FTP software provides a great no-frills testing tool for your FTP site.

Figure 8.4 - When you connect to a protected site, you'll need to make sure you do not enable anonymous login in the FTP client. You may also want to specify a starting directory.

You should test your setup extensively before making it public. Login as a user that you've established and try to upload a file to another user's directory. You should receive an Access Denied error message. If not, be sure you check the properties sheets for the directory, and verify that the security has been set up appropriately. The biggest reason that you may experience problems with the security is the group Everyone. Be sure the rights assigned to the group are appropriate, usually Read-Only.

Don't forget that you must have provided the "Log on locally" right for any account that will be accessing your site. If you don't, you'll receive an "Unable to logon" message, with not much more indication of what the problem is. Check the account's rights and make sure this right is enabled.

Special FTP Options

If you want to take advantage of a built-in feature of the FTP service, you can allow it to assign default home directories. When a user logs in, the FTP Service will look in the default Home directory for a directory with the User's login name. If found, the FTP service will make that directory the user's root directory.

You can put this to good use if you can make some assumptions about what people will be submitting by FTP. If it's largely HTML documents, you can map the directory to the USERS area. If you make the users' subdirectories with the same name as their login name, the effect will be of logging in to FTP and being taken directly and automatically to your respective subdirectory. You can then upload your content for use by others.

To implement this, following these steps:

Create a directory that will contain the user's individual subdirectory.
Assign appropriate rights to the directory, typically making it read-only for all users.
Create the individual user's directories, assigning writable permissions to the directories for the users they are created for.
In the FTP service, point the Home directory to the USERS directory.
In the Web service, create a virtual directory and point it to the USERS directory.

At this point, a couple of things are in place that bring some good usability to people using the system. First, when they sign in with FTP, they're automatically taken to their content area. They'll also not be able to move up and out of the directory area, so you're gaining a level of content security. An added benefit is that you're once again piggy-backing on the security already in place with NT Server. You know that the name the user signed in under will be the directory selected to work in.

Second, the Web service can now provide access to all of the content in these areas with a simple, and pretty logical URL. An example of this URL would be:

http://www.intellicenter.com/users/swynk

where SWYNK is the user name. We've only introduced the USERS directive, which makes sense from the accessing users' point of view since they're requesting personal Web page information with the URL.

A key point to this technique is that this also works for the anonymous user. You'll recall that, when FTP logs on the anonymous user through NT, it uses the user you set up in the FTP service properties. When the service looks for a directory using the techniques outlined here, it will simply look for a directory named ANONYMOUS. If it finds it, it will make it the user's root directory just as it would for other users. You can prevent directory browsing by implementing this as an anonymous user would not be able to see the other user directories on the system.

You will want to consider removing ALL NT rights from the USER root directory. This way, if a user somehow logs on and does not have a home directory, he will not be able to "wander" around the available directories. The users would need to use one of the virtual directories you have established, or it would just appear to them that no files or directories are present.

One caution of this approach with the FTP service is that you'll be locked in to dropping the users into their FTP area. The only way to allow them to browse the site is by creating virtual directories and making them available to the user. Unfortunately, virtual directories don't show up if a simple directory is requested. You must know the directory name to access it successfully.

This drawback aside, by holding the user's hand a bit, you can provide an increased perceived level of service by putting users in the right area for them to begin their work, all automatically.

Setting up a Virtual, or Multi-Home Server

Multi-Home? It may sound like an unlikely candidate for your Web site, but it is key to providing a presence that is easily understood and that provides an added level of control for your users.

Multi-Homing your server really entails two different things. First, you'll be setting up your server on a physical level, allowing more than one access point into the system. Second, you set up logical layer that handles the services and their appearance to the user.

In IIS-speak, Multi-Homing is referred to as a virtual server setup. You establish different settings in the IIS software that respond to incoming requests. In some cases, the handling of these requests differs between access points, while in others the same material may be available across server entry points.

In the next few sections, you'll see exactly what is entailed in setting up your server for this type of access.

Virtual Server Hardware and Operating System Requirements

***Prod: If you can index occurrences of "Multi-Home" to also create Index hits on "Virtual Server(s)," you'll be doing a great thing! Most people do not know one term or the other - Virtual Servers is a Microsoft-only term, while Multi-home is a more standard term. In the context of this book, Virtual Server is correct (see below) but in order for someone to ask the question "How am I going to multi-home this server installation," we'll need to provide that cross-reference in the index.

The hardware-based portion of setting up a virtual server is quite simple. There is no requirement to add hardware but, you may find that your internal network structures require that you do so to address multiple LAN segments or access to the Internet.

Virtual servers rely on IP addresses to know how to work. You'll be associating one or more IP addresses with the network card(s) you're using. In the example shown in Figure 8.5, you can see that the addresses of 198.68.42.72 and 198.68.42.73 have been associated with the system.

Figure 8.5 - You can associate up to five different IP addresses with your server by default.

Of course for each IP address you want to assign, don't forget to create the DNS entry on your server so people can access the system by a more friendly name. A common naming convention is to stick by the root name for your site, perhaps QUE.COM, and preface it with a site-specific name for each unique IP you're setting up. In this type of scenario, you might have a server supporting these different named access addresses:

sales.que.com
support.que.com
intranet.que.com
users.que.com

The Control Panel Network TCP/IP property sheet only allows for five different IP addresses for a given IIS installation. If you require additional Virtual Servers, you'll need to make a change to the system Registry, adding the IP addresses and Subnet Masks manually. The key that you will need to modify is:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\
Services\<NIC><NIC#>\Parameters\
Tcpip

As you can see in Figure 8.6, there are several parameters in this key that are important to the IP resolution for the services. Of special interest are the IPAddress and SubnetMask values.

Figure 8.6 - Setting up additional IP addresses to be supported by the Virtual Server options requires manipulation of the system Registry.

You can see that the display of the values lists each IP address you've assigned, separated by a space. If you double-click on the IPAddress values, you'll be presented with the dialog box shown in Figure 7 that will allow you to enter more addresses to be used by the system. Press Enter after each address you enter.

Figure 8.7 - When you're entering the addresses manually in the Registry, there is no technical limitation to the number of addresses you can assign.

You need to follow the same procedure for the SubnetMask entries. Double-click the existing values and enter the values in the resulting dialog box. When you enter the values, they should be in the same order that they are to be applied to the IPAddress's you entered. When the addresses are resolved, they'll be done so in pairs. The first IPAddress will be paired with the first SubnetMask and so-forth.

After you enter the addresses, you need to restart Windows NT to make the changes take effect. The final step to enabling this technique is to set up the IIS properties for the Web and FTP access. In the coming sections, you'll see exactly how this is done.

Virtual Server Internet Information Server Software Setup - Web Services

Once you've set up the server portion of your system to recognize the IP addresses you need, you will need to begin applying those addresses to your Web services. As you can see in Figure 8.8, you can assign IP addresses to specific directories, even creating a Home directory that is accessed based on the incoming IP address.

Figure 8.8 - Virtual servers come into use on your system by assigning them to directories that can be accessed.

The first thing you'll need to do is to establish the home directory for each IP address you're setting up. This sets up the starting point for access to your server via the address you indicate.

A problem could occur if you are setting up virtual servers and only establish a single home directory with an IP address associated with it. If you leave the IP address blank on the original, you'll notice that the home address you set up with the IP address will become the home page that will be treated as the default. Be sure you establish an IP address for each Home directory you set up, preventing this situation.

Establishing Virtual Server Home Pages

Setting up the virtual server's home page is the same as setting up the initial system home page, with the exception that you must designate the IP address for the Virtual Server. See Figure 8.9 for an example of setting up this type of system.

Figure 8.9 - Once you indicate the Virtual Server a directory will be associated with, only users accessing the system from that IP address will be able to see the content in the directory.

Once you've indicated that directory that will be used for the new Home for this IP address, you need only indicate the IP address that it should be tied to for access. Select the Virtual Server option and provide the Virtual Server IP Address. You'll also need to set up the Read or Execute permissions for the directory.

Once you've set this up, any user accessing your server by way of that IP address will automatically be taken directory to that directory to start on the site.

Virtual Servers are a great way to segregate content on your system when you're sharing your server for both an Intranet and an Internet presence. You can associate one set of content with the IP address associated with the Internet, and you can associate an entirely different set of content for those users accessing over your internal network.
By doing so, you can offer much of the same content across sites, but you'll be putting up a good wall between public users on the Internet and the employees of your company with the private, and perhaps confidential, information on the Intranet.
For more information about this, see Chapter 15, "Migrating your Intranet Site to the Internet."

When you create the home directory, or any other directory associated with a Virtual Server, all directories under that directory will inherit the IP association you set up. In other words, if you set up a directory, <home> which refers to c:\inetsrv\wwwroot\private, all access to the PRIVATE subdirectory and its child directories, will be available to the IP address you set up.

For this reason, if your intent is to provide a public and private access point to your server, you may wish to set up a PUBLIC root and a PRIVATE root, with links between the two as needed. You can always put links on your private pages into the PUBLIC area, providing access to that information as needed.

Also, keep in mind that, once a user has accessed your site by an IP address that you've established in this manner, any time the user, or his related HTML code, refers to the "root," this will be referring to the home directory you're setting up, not the root of the drive or the root of the default Home page.

Once you've assigned an IP address to a home page, any access to your server over any different IP address will not be able to get to the location you indicate, unless of course you've created other virtual directories that point to the same directories.

Accessing Other Virtual Server Web Pages

As you create the virtual directories associated with your Virtual Servers, be sure you also create the fundamental directory pointers. You'll need one for your root, or Home, access. This is what was discussed in the previous section.

You'll also likely need to create a new directory to manage the scripts that you'll make available. The standard directory name is /SCRIPTS, so you'll want to adhere to this if possible. This brings up an interesting and key point about the virtual directories you create as they can have the same alias between Virtual Servers.

Remember, the scripts directory should not have the Read security assigned, but it must have the Execute permissions enabled in order to allow a user to run a script against the Virtual Server.

What this means is that, if you have three Virtual Servers, you can have three /SCRIPTS alias' set up. Each will only be accessed by the Virtual Server you associate each directory with. This is important for compatibility. If you have a site developed with directory naming specifications, you can match the directory names between servers, keep the names of the directories the same, but still use the Virtual Directory features.

It may be easiest to test the IP addresses and Virtual Servers by using the IP address in the URL that you use to access the site. For example, instead of HTTP://HOLODECK3, indicate HTTP://198.68.42.72. You can change the IP address easily on the URL command line to make sure you're getting back the content you expect.
The next step is to try to access the site with the DNS names you've set up. Make sure they map to the correct IP addresses, and ensure that the server is picking up on the IP addresses.

Once you associate a page with an IP address, it's available only from that Virtual Server. If you have a directory that you want to be accessed by more than one Virtual Server, you will need to set up a Virtual Directory for each server that will access the resource. This only applies if you are excluding a Virtual Server from a directory. If you're granting access to a directory for all of your different Virtual Servers, you can do so by not supplying an IP address for the directory. If the IP address is blank, there will be no IP address restrictions of this type imposed on it.

Advanced Management of Your Site

There are a number of different tools you have at your disposal that will help you manage your site, its performance, and the usefulness of the system to the users on it. Once you bring up your network, and after you begin offering open access to the system, you'll need to change into management mode for your system.

There are three different areas that you'll want to keep an eye on to start:

Site accesses and page access counts
Server impact, server loading and overall utilization at your site
Problems that arise, including failed access attempts and other error conditions

Each of these is covered in the next few sections of this chapter.

Site Accesses and Page Access Counts

The first of these areas of interest, monitoring specific page accesses, will be covered in Chapter 11. You may recall that you can run one of the scripts that was provided against your SQL server and see exactly what pages are accessed and how frequently. The following list shows the output from one of these types of queries.

Total hits  Last Access           
----------- --------------------- 
90          May 13 1996  9:06PM   
- 
Hit summary Date     
----------- -------- 
9           19960428 
81          19960513
- 
Time of day Hits        
----------- ----------- 
22          9           
23          81          
- 
Page                                     Hits        
---------------------------------------- ----------- 
/samples/gbook/register.htm              4           
/Default.htm                             3           
/samples/dbsamp/dbsamp.htm               2           
/samples/sampsite/results.htm            2           
/samples/sampsite/taste.htm              2           
/samples/dbsamp/dbsamp1.htm              1           
/samples/sampsite/about.htm              1           
/samples/sampsite/catalog.htm            1           
/samples/sampsite/default.htm            1           
/samples/sampsite/process.htm            1           
/samples/sampsite/sampsite.htm           1

By using and regularly reviewing the results of these scripts, you'll know what information can be removed, and what information is most popular and may need to be expanded. Similar logging is available for both FTP and Gopher services.

One nice addition to the reports would be to break the report based on the user directory that was queried. If you can combine this with an IDC approach, giving the users an on-line resource about what information is accessed most often from their site, you provide a great tool for the users. Consider the following set of files that are found on the CD with this book.

First, the HTML file is listed that will prompt for the user name to query. This is shown in Listing 8.1.

Listing 8.1 8LIST01--SEEHITS.HTM: SEEHITS.HTM prompts for the user name, then passes it to the IDC layer to query the database.

<html>
<head>
<title>Sample Query to Review Site Statistics</title>
</head>
<h1>Please enter your user name below.</h1>
<form method="post" action="/scripts/access.idc">
<input name="user">
<input type="Submit" value="Run Query">
</form>
</body>
</html>

The HTML is simple and doesn't do much, beyond asking for information back from the user. The user will be shown a single text edit box and allowed to enter a value and submit the query. Once submitted, the ACCESS.IDC interface is called, passing in the named parameter, USER. Listing 8.2 shows the IDC file that is used to query the database in this case.

Listing 8.2 8LIST02--ACCESS.IDC: The IDC file contains the SQL query that will be run against the database to determine the accesses that have occurred for the user's pages.

Datasource: Web SQL
Username: Logging
Password: Password
Template: Access.htx
SQLStatement: 
+ SELECT "Page" = substring(target,1,40), 
"Hits" = count(target)
+ FROM logtable WHERE target like '%%user%%'
+ GROUP BY target 
+ ORDER BY "Hits" desc

As you can see, this is the same query that is used to query the database manually, with the exception that the new check on the user name is added. This allows the query to only pull back pages with the user name embedded in them, effectively limiting the display to only those pages pertinent to the signed in user. In Listing 8.3, you can see the HTX file, ACCESS.HTX, that is referenced in the IDC file. This file is used to display the results of the query as they are returned from the server.

Listing 8.3 8LIST03--ACCESS.HTX: The HTX file is responsible for formatting and display of the results set.

<html>
<head>
<title>Page hits for user <%idc.USER%></title>
</head>
<h1>The following hits were recorded for 
your pages:</h1>
<p>

<%if currentrecord eq 0%> 
  <h2>No hits were recorded, sorry!</h2>
<%else%>
  <table border>
  <%begindetail%>
    <tr>
    <th><%Page%></td><td><%Hits%></th>
    </tr>
  <%enddetail%>
<%endif%>

</table>
</body>
</html>

The result is a page showing the user the number of hits experienced on his personal materials, all presented to any remote workstation on the network and not necessarily only on the server. This proves to be very valuable information to test the validity of advertising campaigns, customer assistance and more. You can see, and start to profile, the types of users that are using your site.

Server Impact, Server Loading and Overall Utilization At Your Site

There is a huge array of counters that are installed when you install IIS. Each of these is available from within the Performance Monitor of NT and can be used to profile your site. It's likely that you'll end up with more than one series of monitors running as it really makes sense to look at your server from several different angles. The counters that are installed are broken up into four different areas:

FTP Server
Gopher Server
Internet Information Server
Web (HTTP) Server

In addition, there are third party utilities, such as those from Media House, that will help in the administration of your site. These tools provide additional feedback on the site, including number of current users, their associated IP address, the number of HTTP requests fulfilled and more.

Media House can also be found on the Internet at http://www.mediahouse.com

Table 8.2 shows some of the key counters and what they will tell you about the state of your server.

Table 8.2 - Key IIS Counters
Counter Description

ALL:Bytes Received/sec, Bytes Sent/Sec Indicates the current activity level of the server. This is a good indicator of how hard your services are working to service requests.

ALL:Current Anonymous Users This value will let you know how many non- specific users are currently using your services. For FTP services, these users are usually download-only users and represent someone that may be accessing a file from a link on a Web page, or has been directed to download a file directly using an FTP client. Note that if you reference this value in the display of the counters, you should also include the non-anonymous users (see the next item) to provide a complete picture of the system usage.

ALL:Current Non-Anonymous Users These are validated, authenticated users that the system has allowed to log on. These are users who will typically have more rights on the system and are able to upload files, create directories, have access to secure areas on the site, etc. Note that if you reference this value in the display of the counters, you should also include the anonymous users (see the previous item) to provide a complete picture of the system usage.

ALL:Current Connections All current connections to the given service. Note that this is the same as displaying both anonymous and non- anonymous users as noted above.

FTP:Files Sent, Received, Total These will help you track how much incremental activity is occurring against your system. Of particular interest is the Files Received counter as it indicates that your disk space is being used by new objects on the system.

HTTP:POST requests These requests typically indicate that a user is using a form type of HTML document. These can be helpful if you implement forms and need to know if people are really using them, and you can get a feel for when they are being used. Use this in conjunction with the WWW.SQL log analysis script and you'll be able to see any appropriate impact on your server if you have a heavily forms- based system.

HTTP:Bytes Sent/Sec This number can help gauge the impact on the server a bit better than files sent, simply because it can be disconcerting to see how many files are included in a given Web page. Remember, each graphic is a separate image and file, increasing the file count. By monitoring trends in the Bytes Sent/sec values, you'll be able to see the demand growing and you'll be able to quickly see busy times of the day for accessing the server.

Table 8.2 - Key IIS Counters
Counter	Description
ALL:Bytes Received/sec, Bytes Sent/Sec	Indicates the current activity level of the server. This is a good indicator of how hard your services are working to service requests.
ALL:Current Anonymous Users	This value will let you know how many non- specific users are currently using your services. For FTP services, these users are usually download-only users and represent someone that may be accessing a file from a link on a Web page, or has been directed to download a file directly using an FTP client. Note that if you reference this value in the display of the counters, you should also include the non-anonymous users (see the next item) to provide a complete picture of the system usage.
ALL:Current Non-Anonymous Users	These are validated, authenticated users that the system has allowed to log on. These are users who will typically have more rights on the system and are able to upload files, create directories, have access to secure areas on the site, etc. Note that if you reference this value in the display of the counters, you should also include the anonymous users (see the previous item) to provide a complete picture of the system usage.
ALL:Current Connections	All current connections to the given service. Note that this is the same as displaying both anonymous and non- anonymous users as noted above.
FTP:Files Sent, Received, Total	These will help you track how much incremental activity is occurring against your system. Of particular interest is the Files Received counter as it indicates that your disk space is being used by new objects on the system.
HTTP:POST requests	These requests typically indicate that a user is using a form type of HTML document. These can be helpful if you implement forms and need to know if people are really using them, and you can get a feel for when they are being used. Use this in conjunction with the WWW.SQL log analysis script and you'll be able to see any appropriate impact on your server if you have a heavily forms- based system.
HTTP:Bytes Sent/Sec	This number can help gauge the impact on the server a bit better than files sent, simply because it can be disconcerting to see how many files are included in a given Web page. Remember, each graphic is a separate image and file, increasing the file count. By monitoring trends in the Bytes Sent/sec values, you'll be able to see the demand growing and you'll be able to quickly see busy times of the day for accessing the server.

There are a number of other counters and each is outlined in the IIS help system. Search the system for the term "MIB Definitions" for a table of available counters.

Once you establish the performance monitor characteristics you want to use, you can set up the performance monitor so that you will be able to see at a glance what's happening on your server. There are also several pre-defined Performance Monitor profiles that are included with your server. In the tour directory under the samples that are installed when you install IIS, you'll find four files, all with a primary filename of MSIIS, and each has a different extension associated with the Performance Monitor.

PMA - this configuration is in report alert mode. It looks for exceptions to occur on your system and then notifies you of a potential problem. The predefined set includes monitors on the overall system processor loading for the IIS system, and it watches the use of caching of information on the system.
PMC - the PMC settings provide for graphical monitoring of the overall processor load, the IIS processor load, caching information and the current number of Web Server connections.
PML - the Logging format is extremely helpful for longer-term analysis. You can take a snapshot of your system on a regular basis, log the results to a file and review the file on a periodic basis to make sure things are flowing smoothly. The PML configuration includes FTP, Gopher and HTTP server characteristics, overall performance summary information and counters that relate to the Processes and system states on the server.
PMR - The PMR configuration creates a constantly updating report version of this information. The information includes counters for the INETINFO process and the HTTP server. Several different aspects of each are included, providing for good feedback on the processes.

Once you have just the right settings showing the information you care to review, you will want to consider making this information a permanent fixture on the server as you'll want to know on a moments notice the status of the server, should someone ask or report a problem.

Problems That Arise, Including Failed Access Attempts and Other Error Conditions

There are two different places to look when you experience a problem with your system. The first, which is probably rather apparent, is to review the Internet Service Manager. See that the different server processes are active and running with no apparent problem.

The second is the Event Log. The Event Log is where all notes of problems are stored, regardless of the system, application or process that caused the problem. Figure 8.10 shows an example entry in the logs that indicates that there is a problem with an ODBC datasource.

Figure 8.10 - When you reference the Event log, always be sure to review both the Application and System logs. Between these, you're likely to find the problem.

The two key areas of the event log are the Application and System areas. If you have a problem, chances are very good that it will be detailed within these two logs. By the same token, if you can't find the problem in the logs, it's a good indication that you may have a problem at the client side of the picture, rather than the server.

Unfortunately, there are a nearly infinite combinations of messages you can receive with the event viewer, so outlining problems and solutions here would not be helpful. Just be sure to read the descriptive text of any problems you encounter and you should be able to correct the problem, or at least properly convey to the situation to someone who can fix the problem.

Considerations for Site Testing

One thing that you can't do enough of with your Intranet is testing. Nothing turns people off at a site faster than a broken link, a passworded area that doesn't grant appropriate access, or completely off-standard implementation.

In testing your site, especially in the case where you're setting up at least one Virtual Server, you'll need to test each service, each directory tree with each incoming IP address. Remember, security is applied differently depending not only on who you are to the system, but also based on the Virtual Server you're using, the access rights at the NT Server level and the access rights at the IIS level.

It may sound strange, but if you have a chance to, it's probably best to break the system and then figure out how to correct the problems you've created. If you have access to a different server, one other than the production system, it's probably a prime candidate for this type of testing. It sounds strange to break your system to test it, but it's the best way to learn and experience the things that can happen with a system.

Barring the availability of an alternate system, consider the following as you are testing:

Be sure to log in as several different users. If you are the system administrator, the fact that you can access a specific portion of the system does not mean it's configured correctly as it relates to security. Remember, you have full access to the system as administrator. You should try accessing the system with a user whose rights are the absolute minimum and work up from there.
Try logging in from different workstations. This helps test the IP limitations you may or may not have implemented. This also varies the user environment a bit, allowing you to see any obvious incompatibilities between the software you're using and the software on the users' systems.
Try logging in from different LAN segments. This will confirm that your DNS and/or WINS servers are working correctly to resolve names.
If you're using Virtual Servers, try gaining access with their English name and their TCP/IP address. The results should be identical. Do ALL IP addresses work for accessing the system?
Remove the user that you're testing with from the system. Try to gain access again. Does it work? If so, check to make sure the Guest user account is disabled.
Use Netscape to access your site and attempt to gain access to protected areas. Are you able to access these areas, and are you properly prompted for your password? Does passing in your password work? If not, make sure in the WWW properties that you've selected the clear text option.
Use Internet Explorer to access your site and attempt to gain access to protected areas just as you did with Netscape. Do you have any different results? Are you able to gain access to the protected areas of the system?
Can you upload files to someone else's FTP area?
Can you delete files from their FTP area?
Can you upload files to your FTP area?
Can you create new directories in your FTP area?

Once you've been through your site testing, do it again, but with someone else doing the driving. Teach them how to access the site. Watch what they do, how they expect to do it. This is perhaps one of the best learning tools available in designing access methods, how procedures work and, most importantly, how the user expects them to work.

Reality Check

It is a major goal of the IntelliCenter site to provide Internet and Intranet access to students and potential students. From the internal network, students are provided with the ability to create pages that are their own, personal pages. To accomplish this, the user areas mentioned earlier in the FTP and Web sections have been implemented. Students have upload capability only to their directories on the server. They have read-only access to all remaining areas.

The tools to analyze site performance and page-hits are implemented, and provide good feedback on the popularity, or lack thereof, of different features on the site.

The actual class time does not include Intranet time, unless of course the class was based on that technology. Instead, the site is available to students on breaks and before and after class. This seems to help break up classes by changing the technology focus entirely on these times.

One of the things that tends to trip up the flow of things is the fact that there is no mechanism for automatically creating user directories on the system when a user is created. If you forget to add the user directory to the system, rather than being placed into their directory automatically as needed, the user is presented with an empty directory and no way to upload files. This can be confusing to someone just learning to use the system. Several checklists have resulted, making sure several different things occur when students are first created on the system:

They are created as an NT user.
They are created as a SQL Server user (integrated security is not implemented at this time) and given access to the TRANSCRIPTS database.
The user directory is created.
Directory rights are assigned.

When the user is first created, the user account is created by copying a predefined "STUDENT" user. This is to make sure the proper groups are assigned and that the user receives the required "Log on locally" user right, another common stumbling point in creating new users with access to the system.

After putting a process around creating student users, the system works well and provides the protection needed, giving the students a good resource to experiment with Internet techniques and approaches. Since the system is also published to the Internet, in cases where the corporate account has approved it, the student's personal Web pages may also be made available on the Internet as showcase pages.

From Here

In this chapter you've seen how you can take your server to the next level, providing upload services, dynamic access to the system and more. You've also seen some of the different tools you'll be using to manage your server. From here, you can check into the following materials for more information:

In Chapter 11, "Building Databases for Intranet Access," shows how you set up the datasources for this critical logging information.
Chapter 12, "Using Microsoft Office Assistants to Create Web Content," shows more about the tools you can provide your users to help them get up to speed in the creation of content.

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.