Share via

IIS Insider - October 2001

  • Article

Top 5 Questions and Answers on Internet Information Services

By Brett Hill

How To Install IIS 5.0 on a Separate Drive

Q: I have a Windows 2000 server and I would like to install IIS 5.0 on a separate drive. When I go into Add\Remove Windows Components (in Control Panel), I can of course select IIS but I don't see any prompt giving me a choice as to where it will install. Due to my particular group's standard, we need to install IIS 5.0 on a drive other than the default (the "C" drive); specifically the "E" drive. So my question is, how can I install IIS 5.0 for Windows 2000 on a separate drive?

A: If you've installed IIS 4.0, you're accustomed to being asked where you would like the default website and sample files to be located. Like you, many administrators are surprised to find that IIS 5.0 is installed by default to the %systemroot% folder without asking you where you would like for Inetpub to be located.

You can, however, place the Inetpub folder contents wherever you would like if you perform an unattended installation using an answer file. This is possible through the use of the SYSOCMGR (System Optional Component Manager) utility provided with Windows 2000. Don't despair, as it's really very simple.

  1. Before you begin any process of this sort, it is recommended that you make a complete system backup.

  2. Uninstall IIS using the Control Panel, Add/Remove Programs, and Add/Remove Windows Components option. Then clear the checkbox next to IIS. Answer the prompts until the Add/Remove Programs utility uninstalls IIS.

  3. Create an answer file that is used by SYSOCMGR to configure the installation.

  4. The answer file is a text file that can have any name (iis.txt is fine).

  5. It must have a specific structure as follows:
    [Components]
    iis_common = on
    iis_inetmgr = on
    iis_www = on
    iis_ftp = on
    iis_htmla = on
    [InternetServer]
    PathFTPRoot=D:\Inetpub\Ftproot
    PathWWWRoot=D:\Inetpub\Wwwroot

  6. Use the Sysocmgr.exe command (at a command prompt) to start the installation. Assuming the answer file that you created in step 1 was named iis.txt, the command line to execute the installation is:

    sysocmgr /i:%windir%\inf\sysoc.inf /u:c:\iis.txt

The installation will proceed with the Inetpub installed on drive D as specified. You can use any drive you like, of course. Note that this does not relocate the IIS binaries as they must be located in *%systemroot%/*inetsrv.

In addition to installing FTP and IIS, there are many other options that allow you to specify what IIS components you'd like to install including NNTP, SMTP and Front Page Server Extensions.

It is important to know how to use SYSOCMGR to do an unattended setup of IIS 5.0, but if your intention is to relocate the content in Inetpub, there is an easier way. The administrative website is not located C:\WINNT\System32\inetsrv\iisadmin by default and is not in Inetpub. The Default website has only a few files and folders and some virtual directories that map outside of Inetpub. This makes it quite easy to relocate the home of the Default Web Site to any drive or folder you wish by simply copying the content to the new location and then changing the Local Path in the Home Directory tab to show the new location. Additionally, you can create new websites on any drive you wish. Consequently, while you can use SYSOCMGR, it is usually not necessary simply to relocate the Inetpub directory.

For additional information on unattended setup, see the Microsoft Windows 2000 Guide to Unattended Setup. This document can also be found on the Windows 2000 product CD-ROM. To view it, extract the Unattend.doc file from the \Support\Tools\Deploy.cab file.

How to Customize Name and Location of Metabase.bin

Q: For security reasons, we would like to relocate and rename the metabase in IIS 5.0. There doesn't seem to be any way to do this in the IIS snap-in. Is there some setting that allows us to customize the name and location of metabase.bin?

A: Metabase.bin, which stores most of the settings pertaining to IIS, is located in the %systemdrive%\%systemroot%\winnt\system32\inetsrv folder, which is normally C:\winnt\system32\instrv. The metabase is essential to the operations of IIS and consequently, many administrators seek to change the name and location of the metabase primarily for security reasons.

As a security technique, relocating and renaming the metabase falls into the category of "security through obscurity" which many security experts avoid. Keep in mind that the metabase NTFS permissions are set, by default, to Administrator and System – Full Control. With these settings, no user can access the metabase. Additionally, if a hacker did gain access to the server as the System or Administrator, a renamed and relocated metabase would do little to protect you.

Nevertheless, you can rename and relocate the metabase by adding the following value to the registry key HKLM\Software\Microsoft\Inetmgr\Parameters
Value: MetadataFile
Type: REG_SZ
Data: Path to metabase (for example C:\winnt\system32\inetsrv\metabase.bin)

How to Place Content Outside the FTP Root and Have Clients Access Folders

Q: We would like to place FTP content outside or our FTP root. When we create a virtual directory, clients cannot see them in the directory listing when they access the FTP server. How can we place content outside the FTP root and have clients access the folders.

A: Microsoft's FTP server, although basic, has a few tricks. One of them involves just this kind of situation. You are quite right that the virtual directory is "invisible" to FTP clients. That does not mean, however, that it is not accessible. You can in fact issue a change directory command and be transported to the Virtual Directory home folder, which can be outside your FTP root. The trick is to place a regular folder by the exact same name as the Virtual Directory in the FTP root. Then, when clients access the FTP server, they will see the "regular" folder. However, when they try to open the folder, they will instead be transported to the Virtual Directory.

The only difficulty with this technique is be sure to recall that if you place content in the "regular" folder, it will not be seen by the client.

Starting Site After Implementing Host Header Results in Error

Q: We have several websites on our IIS server. Recently, we decided to implement Host Header on each site. We can successfully add the host header to the sites; however, when we try to start the site, the error message below appears:

If your browser does not support inline frames, click here to view on a separate page.

What could be causing this?

A: This is a very common configuration problem that, fortunately, is easily resolved. To convert a website that is using an IP address to one that is using a Host Header, click the properties of the Default Web Site in the IIS snap-in. Click the Web Site tab and then the Advanced button as shown if figure 1.

If your browser does not support inline frames, click here to view on a separate page.

Figure 1 Default Web Site Properties

This will display the Advanced Multiple Web Site Configuration window as shown in figure 2.

If your browser does not support inline frames, click here to view on a separate page.

Figure 2 Advanced Multiple Web Site Identities

Since you want to add a Host Header to this website, it would seem to make sense to click the Add button. After all, it is the only button available to choose. If you do so, and add your host header entry, you wind up with two entries in the Advanced Multiple Web Site Configuration window as shown in figure 3.

If your browser does not support inline frames, click here to view on a separate page.

Figure 3 Multiple Identity Entries

This highlighted entry correctly instructs IIS to have this website respond to an HTTP request on any IP address that is not assigned to another website if the URL is https://NewSite. The first entry, however, tells IIS to respond to an HTTP request on any IP address that is not assigned to another website, no matter what the URL contains. This first setting is exactly the same as the Default Web Site and so the two are in conflict.

Instead of clicking the Add button in figure 2 to add a Host Header, select the existing host header entry. That will enable the Remove and Edit buttons. Then you can edit the existing entry and add the Host Header.

The resulting, correct entry will have one (or more) entries, but each with content in the Host Header Name column.

How To Set Limits on the Size of the URL

Q: We've noticed in our logs that when someone tries to penetrate the server, they often send the server a very long URL. It seems like we could prevent a great number of past and future hacks if IIS would not accept long URL's for processing. Is there a way to set such a limit in IIS?

A: Indeed there is. You are quite right in that many attacks on an IIS server involve sending actual programs in the URL. By limiting the size of transmission that IIS will accept from the client, you can seriously restrict the attack methods available to a would-be hacker.

By default, IIS does have a limit on the size of the URL plus the HTTP header fields. In IIS 4.0 that limit is 2 MB. In IIS 5.0, the limit is 128 KB. Both of these values are quite large for general use and this threshold can be lowered.

Use the Registry Editor (Regedt32.exe) to locate the key HKLM\CurrentControlSet\Services\W3SVC\Parameters. Add the value MaxClientRequestBuffer and enter as a REG_DWORD the maximum number of characters in decimal that you wish to accept in a URL, plus the header size of the HTTP transmission. For reference, to send https://localhost/iishelp/iis/misc/default.asp requires MaxClientRequestBuffer be set to about 5000 (decimal).

This setting works in IIS 4.0 (SP5 or greater) and IIS 5.0.

If you do use this setting, use POST instead of GET to send information from HTML forms as the POST method sends form field data in the body of the transmission. The GET method uses the URL.

For more information see, the Microsoft Knowledge article Q260694.

In addition to the registry editing, Microsoft has release a tool called URLScan that inspects incoming requests to IIS and filters them according to a ruleset created by the administrator. URLScan is very effective at filtering unwanted URL's such as those from the Code Red or Nimbda worm. It is recommended for use only by experienced administrators since it requires some understanding of HTTP in order to effectively construct rules. Look for more information about URLScan in the next IIS Insider column.

Submit your questions for the IIS Insider. Selected questions along with the answers will be posted in a future IIS Insider column.

For a list of previous months questions and answers on IIS Insider columns, click here.

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as is," without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages.