The Administration Web Site

Managing Web sites remotely has pros and cons

The Administration Web Site, which is part of the default IIS configuration, lets you use Microsoft Internet Explorer (IE) to remotely administer IIS. The Administration Web Site is a good tool for basic administration of IIS servers that aren't accessible through the Microsoft Management Console (MMC) Internet Information Services snap-in—for example, IIS servers in a demilitarized zone (DMZ), in which remote procedure call (RPC) access is blocked from all locations.

Security Precautions
The Administration Web Site can be a security risk, but if you configure it properly and monitor access to it, you can minimize the risk and make its use worthwhile. To minimize the security risk of the Administration Web Site, you should apply as many of the following recommendations as possible:

First Impressions
The Administration Web Site is easy to use, but like most HTML versions of Win32 applications, it loses a little in the translation. The site is slightly slower than the Internet Information Services snap-in. Also, the administration interface, which Figure 1 shows, is awkward to use at first, and you can easily lose your place. For example, if you have multiple virtual directories named Cgi in different Web sites and you open the Properties dialog box of one of the Cgi directories, you'll see the directory name in the left pane. However, you have no easy way to tell which Web site you're working with unless you go to the main Directory Properties page, which Figure 2 shows. If you're using the Administration Web Site to make a lot of changes to multiple sites, you might find it difficult to identify which server and site you're on.

In addition, the Administration Web Site doesn't perform adequate error checks. Thus, if you aren't careful when using it, you can make mistakes that jeopardize your Web sites' operation. I describe some of the missing features later in the article.

A New Web Site
When you set up a Web site in IIS, the Administration Web Site gives you the same choices as the Internet Information Services snap-in does, with a few exceptions. The Administration Web Site doesn't provide a drop-down list of physical IP addresses to choose from for the new site. Thus, you must know the IP address that you want to use for the Web site or leave the field blank for an unassigned address. In addition, you can't set any host-header information when creating a Web site, but you can add it afterward.

The Administration Web Site provides two capabilities that the Internet Information Services snap-in doesn't provide: the ability to create a physical directory on the hard disk and the ability to remotely administer the Web site you're setting up through an HTML interface. When you select the Site operators can administer this site remotely option during Web-site creation, IIS sets up an IISADMIN virtual directory for that site. This virtual directory allows remote administration of the newly created Web site. The Internet Information Services snap-in doesn't have this option because by default it doesn't allow HTML administration of individual Web sites. However, you can manually add the IISADMIN virtual directory to any Web site in the snap-in. I don't create the IISADMIN virtual directory for individual Web sites because applying security restrictions to an individual directory is harder than applying them to a Web site.

A Few Differences
You set up a virtual directory in the Administration Web Site the same way you do in the Internet Information Services snap-in. However, the Administration Web Site has a bug that might discourage you from using the Web site to change a physical directory into an application directory. When you use the snap-in to convert a physical directory into an application directory, IIS changes the directory's key type in the metabase from IISWebDir to IISWebVirtualDir. The Administration Web Site doesn't properly change the key type; thus, the Administration Web Site will continue to display the application directory as a physical directory, not as an application directory. The snap-in makes the change correctly.

The Administration Web Site also lacks some of the snap-in's error-checking features. The site performs no error checking when you use it to set up script mappings. You can type in the wrong path or any other information, and the Administration Web Site accepts and saves it. If you access the Script Mapping tab in the snap-in, you won't see the incorrect script mapping. If you want to correct or delete the misconfigured script mapping, you might need to do so in the Administration Web Site or in the metabase (if you can't access the misconfigured information in the Internet Information Services snap-in). The Administration Web Site also lets you type in a nonexistent filename when setting up an Internet Server API (ISAPI) filter. The site tells you that the file doesn't exist, but if you click OK and then click Save in the bottom right corner of the page, it adds the ISAPI filter anyway. If you subsequently try to access the ISAPI Filter tab through the Web site's Properties dialog box in the snap-in, you get the error The specified metadata was not found. If you then click OK, you'll see the ISAPI Filter tab, but it won't list the bad filter. Again, you must use the Administration Web Site or edit the metabase to correct the problem. A bad script mapping or bad ISAPI filter can leave some or all of your Web site inoperable until you resolve the problem.

In the Internet Information Services snap-in, when you change a property at the site level, you might see a dialog box asking whether you want any or all of the child objects listed in the box to inherit the change. The Administration Web Site asks whether you want to inherit the change, but your decision affects all or none of the child objects—you can't select one or more objects. The Administration Web Site's box, which Figure 3 shows, gives you the option to prevent the box from reappearing. Your choice is permanent for the current session. If you want to change your inheritance choice, you must close IE and reopen it.

The Administration Web Site's Permissions Wizard is also limited. You can use the wizard to set Web site security values such as Anonymous access by selecting templates you've installed on your system. But you can't change a server's file permissions the way you can with the snap-in.

You can't use the Administration Web Site to create or install SSL certificates, but you can use it to modify some simple SSL settings. You can set up FTP sites and virtual directories with the Administration Web Site the same way you set up Web sites and Web site virtual directories. However, you can't perform the following tasks with the Administration Web Site: configure server extensions, set up membership server mappings, configure SMTP settings, and rename physical directories.

Despite the problems and limitations I've pointed out, the Administration Web Site is a helpful tool for experienced administrators to use for simple tasks such as creating Web sites and virtual directories, modifying and removing unwanted script mappings, or simply verifying a setting from a remote location. Just remember that securing the Administration Web Site is the first thing you should do after installing it.