This chapter covers some of the highlights of Web server administration. This is a topic that can—and has—filled entire books. I will not replicate all that detailed information in this chapter. Rather, I cover a few thoughts that you might
want to consider when starting out.
A Web server is an amazing tool. It can enable you to present a wide range of information in some fascinating formats. You can provide text, graphics, video, audio, animations, and even applications to your users. You can link to other Web servers
located anywhere on the Internet to access their capabilities. The standard protocols enable you to present your information to users with UNIX workstations, PCs, and even Macintoshes without any great problem. It may seem as if you are limited only by the
amount of time you have to spend working with this system and your creativity.
There are a number of issues that have to be dealt with when it comes to Web server administration, however. Those of you used to formal application environments may find the Web site a little loose in terms of its structure and control. As with any
young technology, there seem to be so many changes swirling about. You probably have a number of questions about when and how to implement these changes. Here are a few issues that seem most challenging to me:
The first is control over content updates. Your NT Server will have one or more directories that contain the content that is provided to the user community. You need to put some thought into controlling who is allowed to update your content and how they
are going to accomplish this. One solution that I have implemented is to make a root Web directory that is shared using standard Windows NT directory sharing. I limit access to this root directory to a few Web masters who are experienced in the subject and
who are responsible for the overall content of the system. Other users and project teams also want access to Web resources, however. I have shared several of the subdirectories under the root Web directory and given access grants to the appropriate NT user
groups. Figure 17.1 illustrates my example.
FIGURE 17.1. Sample shared directories for Web content.
This may not be the perfect solution for your needs. You might, for example, need to provide FTP capabilities to allow users of UNIX workstations to upload new content. You might need to have a much tighter control scheme, where authors put updates into
a staging directory. This directory is then reviewed by the Web master (such an interesting term—everyone else is an administrator, but these people are masters). If the content passes muster, it is transferred by the Web master to the appropriate
directories on the Web. You might consider adapting your software building procedures to Web content if you need to have some form of control.
A related topic that you need to think about is how you will keep your content organized and up-to-date. Web sites are a loose collection of files whose links are determined by the internal content of the Web pages. Although there are some explorer
tools that let you see the structure of a Web site graphically (for example, FrontPage, as shown in Figure 17.2), for the most part you have to know the content well enough to keep the site running.
FIGURE 17.2. FrontPage Explorer tool.
There are several issues related to organizing content. The first is ensuring that you have all the needed files. A tool such as the FrontPage Explorer shown in the figure can help with this somewhat. In the end, however, you wind up testing your pages
to make sure that you can exercise all the links and that all the graphics display. It can be tricky, especially if you link to external sites, which can move or disappear without any warning.
The second content organization issue is whether you need to keep previous versions around and store a backup copy of the files. Authors can spend quite a bit of time on some pages and graphics. What happens if you have an author who names a graphics
file or Web page with the same name that another author used? If you copy the files into the Web root directory, you have just wiped out the old content. One solution is to use a version control system such as SourceSafe, which keeps old versions of the
files. Another might be to divide the Web into a series of subdirectories that keep content from different project teams or authors in separate folders. This minimizes the chance that files will be overwritten.
Another issue to deal with on your Web site is the idea of HTML extensions. The original HTML specification was great for its day, but the moment the Web became popular, a lot of bright people starting thinking up ways to improve things. Different Web
browser vendors adapted one or more extensions to the basic HTML specification. It became difficult because authors often required users to have a specific browser to visit their Web sites, due to the extensions that they were using. This defeated the
purpose of the HTML standards. The major vendors got together under the auspices of the World Wide Web Consortium, and they are working on an updated HTML standard and some other standards that will bring the feature sets back under some standard control.
Until then though, you may run into sites that require some extension, such as frames, that your browser may lack. You need to consider this when you are setting up your Web site, because you will want authors building to some standard level of HTML to
ensure that your clients can actually read the wonderful pages that are written.
Another issue that is creeping up in the Web world is that of active servers. This is sort of a marketing term that embraces a wide range of technologies. It is designed to cover those technologies that enable the server to make decisions based on user
responses, algorithms input by developers, or even the content of a database that controls the HTML Web page content sent out to the users. This ranges from a very simple technique of sensing the type of browser that the user is working with and adjusting
your content to match the capabilities of that browser to complex systems that draw information and send updates to large databases, such as those used in Internet commerce. You need to think seriously about which of these features might be used on your
site, because it will greatly impact the processing and memory loads on your server. My recommendation would be not to implement these features unless you have tried them out in a test environment and can be sure that the load is within the capacity of
your Web server.
Just as you need to be conscious of which of the HTML extensions you are using in your Web pages, you need to think about the active client features that you are implementing. Similar to active servers, active content is a term that embraces a range of
technologies that download software to the client workstations. This downloaded software is executed on those client workstations and controls the information that is displayed to the user. Examples of this technology are the JAVA programming language and
the ActiveX technologies from Microsoft. You need to be sensitive as to which technologies you are using, because the client computer needs to be able to execute them. For example, you need a JAVA interpreter to run JAVA applications, and ActiveX clients
do not work on all browsers and operating systems. Make sure that your target audience is capable of taking advantage of any active client features that you implement.
Because most Web sites are concerned with distributing information as opposed to collecting it, you have fewer worries than you would on an FTP site, for example. You do have some concerns about the information that you are distributing, however. Many
companies are sensitive about prices and new product information. If you are connected to the Internet, your competitors could surf into your Web site and gather information that you really wanted to give only to your customers. You might want to consider
having a group of people get together and determine what is considered appropriate information to give out on the Web server and what information should be restricted (for example, only users who have logged in using valid Windows NT logons would have
access to a subdirectory on the Web site that has NTFS file permissions set to allow only specific groups access). You learn about security in more detail later in this chapter.
The final topic that you might have to deal with is limiting the load placed on your server. Chapter 16, "Setting Up IIS," covered a number of the properties pages for the Web server product. With these pages, you can
control the data transfer capacity that was devoted to IIS and also the maximum number of current connections. If you feel that you might be inundated (or have already been overloaded), you might want to set down these values until you reach a happy medium
between user service and server capacity.
Chapter 16 also covered the default Web user account, which allows anonymous access. You also learned that you have the option to use clear text user IDs or the Windows challenge/response mechanisms if you make users log on with
their own accounts. If you have a Web page that is designed to allow everyone in the world to access all its content, the anonymous access account will serve your needs. This section explored some of the user account-related topics between a Web server and
system administrator who is supporting Internet Information Server.
Windows NT is an operating system that bases all accesses on a logon ID and password. All activity on the system is associated with a logon ID. In the case of the Web server, the users have the option of passing in their user ID and password. This is
not commonly the case. Almost all access on the current Web is accomplished by users who do not pass any identification. The Web servers are designed so that when they do not receive a logon ID, they will try to use a special logon ID that is designed for
anonymous access. In the case of Internet Information Server, that anonymous ID is IUSR_computername.
Most access to Internet Information Server and other Web servers is through anonymous user IDs. These allow anyone on the network to access (but not write to) the content of the Web pages.
How does this anonymous access scheme fit into the NT security scheme? When users do pass a logon ID and password, IIS will attempt logon to the NT Server as those people. When those people try to access files, their personal and group security
privileges will be used to make the decision to grant or deny the access. If there is not a logon ID and password associated with the user and anonymous logon is permitted in IIS, IIS takes on the identify of IUSR_computername, and the privileges of
that user ID is used to make the decision to grant or deny access.
The IUSR_computername account is typically not a very powerful account on your system—for good reason. The only system privilege that it needs is the capability of logging on locally to the computer on which IIS is running. This is because
the IIS process seems to be a local user to the operating system. The only group membership that this account will have is that of the guest group. Therefore, you should make sure that you have not granted any special privileges to members of that guest
group.
When initially created, IUSR_computername has a randomly generated password. You can change this password to something else, but it should be relatively hard to guess. Because the IUSR_computername account does not have access to network
resources by default, even if the password is compromised, users cannot use this account to access some of your directories. I avoid granting this user any access privileges (for example, the ability to transfer content into the Web directories for
maintenance purposes). Instead, I grant these privileges to real users who are functioning in the authoring capacity. I leave the IUSR_computername account a stripped-down user ID that has full read access to my Web directories, but no other
capabilities.
Speaking of user accounts, when you are an Internet or intranet server, you have attracted attention to yourself. Your domain name or IP address is now public knowledge. Everyone knows about you and that you have some interesting content. Because you
now have so much attention, you should consider looking at the other accounts on your system for security. For example, if you use IIS, you will have an account with a logon ID of administrator. You will also have a few other accounts such as guest. If you
have null or easy passwords on these accounts, you have left a security hole right where a hacker would first try to penetrate your system. You should review your overall security policy to see whether your passwords are secure enough.
A few other recommendations include looking at who has access to resources. One of the safest Web servers is one where the Internet connection comes into one network card, and IIS and its protocols are the only ones that are bound to that network card.
You use another network card to provide access to the server from your local area network. You would have a few more network services available on this card that would allow you to transfer files, and so forth.
Other things that you should watch out for include checking what policies have been set for your system. Do a lot of people have accesses beyond the basic user level, such as those provided by the domain administrator role? If you can keep down the
privileges of users on this server, even if someone hacks into one of their accounts, they would not be able to do damage. Of course, it would be ideal to have an Internet server that had no functions other than IIS; then you would not really need to have
many user accounts (only the administrator and those people involved with maintaining IIS and its content).
One final account issue to consider is where is the IUSR_computername account created? If you are running IIS on a primary or backup domain controller, the account is created for the domain. If you are running IIS on other NT computers, the
account is created on the local machine. This is not a particular concern unless you have granted a lot of privileges in your domain to everyone or guest.
Your approach to content maintenance will vary according to the complexity of your Web site. Basically, I would recommend keeping the complexity down to the minimum level needed to get the job done. If you need to distribute information across multiple
disk drivers or even multiple servers, however, IIS does have those capabilities. There are three basic configuration options that you need to consider (see Figure 17.3).
FIGURE 17.3. Basic Web site configuration options.
The first option is your simple site where everything resides under the single root directory. You can put subdirectories under this main directory. To access content in a subdirectory, add the subdirectory name after the domain name. For example, to
access the file joe.htm in the users subdirectory under the main root directory of a Web server whose domain name is www.orange.com, you enter an address of http://www.orange.com/users/joe.htm. You can use subdirectories to segregate different types of
content (all graphics in one directory and all executable CGI or JAVA scripts in another). You could also use subdirectories to allow different individuals to contribute content. In this case, you might have three project teams that have their own Web
pages. You keep control of the master Web pages that are located in the root directory and create a share name that only you have write access to. You then create share names for the project Web subdirectories and grant access to the appropriate project
team members for these directories.
The second option is to create multiple directories located on different parts of your hard disk system. For example, if you have a really large Web site, you might have to spread the contents across several disk drives just to fit within disk capacity
or to balance the data transfer loads between drives. This is also relatively simple. In IIS, you use the Directories Properties page for the Web server in the Internet Service Manager shown in Figure 17.4. You can add directories to this list and give
them aliases. An alias makes a directory located anywhere on your system look as though it were a subdirectory of the root directory. In the example given in the last paragraph, you could have the users subdirectory on the d: drive and the Web root
directory on the c: drive. You would set up the d:\users directory to have an alias of /users. To access the joe.htm page, you would type http://www.orange.com/users/joe.htm, as you would in the case shown previously. You can even use shared directories on
other computers located in your domain, although this could present a network performance problem if you have to do a lot of transfers. To use a network drive, just use the UNC name (that is, \\tester\Web_pages for the tester server’s Web_pages shared
directory). Note that you cannot use redirected drive designations to access shared drives on another server for IIS (that is, if you shared \\tester\Web_pages as your f: drive, you could not use f:\ in IIS; you would have to use \\tester\Web_pages
instead). This concept is referred to as creating virtual directories.
FIGURE 17.4. Configuring directories for a Web server.
The third basic configuration option is to use multiple servers that are running IIS. This concept is simple once you are comfortable with the concept of links. You have a main Web page on your primary server that has the registered domain name. When
users want to go to another page, you use a link to reference them to that page. They are not responsible for understanding the details of the connection; they merely click on the text that you have provided or the right section of a picture. You usually
have this link pointing to another page on your current server; however, there is nothing stopping you from making this a link to another server in your computer complex that is running IIS. This machine could even have a different connection line to the
Internet to balance traffic loads. If you are into a little programming, you might even write scripts that could help you determine which of many identical machines to send the user to in order to balance the load.
Another concept that you should be aware of is that of the virtual server. You have one physical computer running IIS. You have registered a number of different domain names for that computer (and therefore have a number of IP addresses), however.
Windows NT enables you to add multiple IP addresses to a single network card, and you can also use multiple network cards. Each of these virtual servers can have its own home directory and default page. Therefore, you could set up a
marketing.yourcompany.com and a techsupport.yourcompany.com that are both located on the same server. One would start off with a page designed by marketing and the other with the technical support page.
One thing to note is that you set a default filename for your system in IIS setup. This means that if someone types your domain name, they will automatically load the filename that has this default filename located in your Web root directory. However,
this default filename applies to all directories within your Web. Therefore, if someone types www.oracle.com/users, IIS tries to load a file that has the default filename but was located in the /users subdirectory or directory referenced by that alias.
This is a useful technique to save users from typing. Remember, they are getting used to point and click—they may have forgotten how to type.
Let's look at your options for traffic control on your Web server. You usually have very little control over the demand. Users will access the site when they want it and if you have great content, they may come in droves. Your control is basically over
the supply side of the equation. Here are a few tricks that can help you control how much information you are supplying and therefore how much load is being placed on your poor server:
One thing that you might consider about content is the use of a version control system and backups. It is easy to make mistakes and overwrite Web pages (there are going to be a lot of default.htm or index.htm pages out there). If you do not keep backup
copies or use a version control system such as SourceSafe, you may not be able to recover content that you overwrite. If you have a fair amount of content or spend a lot of time and money making truly artistic Web pages, it might be worth your while to
implement such as system.
Here are some other security recommendations that you might want to consider for your Web site:
If you need additional security, consider using the Secure Sockets Layer (SSL) authentication scheme. You send away for a key that gives you a unique ID for your computer (see the Key Manager discussion in Chapter 16). This ID
enables you to identify yourself for encrypted transmissions over the Internet. This would, for example, enable you to send financial information, such as credit card numbers, without worrying about who would see it.
If you have an FTP server that allows uploads, you may want to check out what has been placed on your server every now and then. Some people like to use servers for purposes for which they were not intended. You have to be the judge as to what content
is appropriate. You also need to be concerned that your server is being used as an incubator for computer viruses. I suggest that you monitor things routinely to see what has been placed on your machine. You could automate the process by running a script
that searches for files that have extensions that are not within the intended purpose of your server (look for all jpg or gif files if your server was not intended to store pictures, for example). Just a thought—some places might blame the
administrator for content that was placed on there by unknown users.
There are a couple of other things to remember. The first is that you can install just the Internet Service Manager on a computer. A good use for this type of installation would be to put Internet Service Manager on your desktop computer and use it to
control all your Web servers from the comfort of your desk. To do this, you use the connect option as discussed in Chapter 16. You need to have a domain set up to make all the security accesses work properly, but you will probably
be moving to a domain anyway, so why not start now.
Another point is the value of scripts, mail, and the AT utility. It seems that most administrators get very busy and called off on other projects soon after they get a new system working. They rarely get the time to go back and review their systems in
the manner that they had originally intended. If you spend a little time up front building some batch files (or other programming tools if you are so inclined) that you set up to run routinely and send you the results by electronic mail, you will be able
to keep up with the status of your system with relatively little pain. Just make sure that you include the script building as part of the basic project.
This chapter covered some food for thought on the subject of being a Web administrator. There are entire books devoted to this subject if you are really getting into maintaining large sites. Although there are some features that you might find in other Web server products, IIS has most of the important features and is combined with the easy-to-use Windows NT operating system. This provides you with a lot of capabilities for automating your system. All you have to do is be careful to ensure that you have a good security setup and that you control the traffic so that your server can provide good response times.
