Internet Information Services (IIS) FAQ

There are a number of ways to do this. The properties and values set in the Internet Information Services Manager console (the IIS snap-in) are stored in the Metabase.bin file located at C:\winnt\system32\inetsrv by default. In IIS 5.0, you can back up the metabase from inside the IIS snap-in. To do this, select the computer icon and right-click. Then select Backup/Restore configuration. You can then choose to back up your current metabase settings or restore a previous version. This same option is also available in MetaEdit 2.2.

When you save the metabase in this way, your backup is stored in the C:\winnt\system32\instrv\metaback folder as an .md0 file. The file will have the name you assigned when you made the backup, such as Pre-Lockdown.md0. If you create multiple backups with the same name, they will have incremental extensions such as Backup.md0, Backup.md1, and so forth.

In the event that your metabase is seriously corrupted, you may be unable to start IIS. In that case, you will not be able to do a restore from the IIS snap-in or metaedit. Should this occur, you can restore by replacing Metabase.bin with the most appropriate .md0 (.md1, etc.) metabase backup file from the metaback folder. Assuming that your backups are good, IIS will start right up.

There are two other means to make a backup of the metabase. You can simply copy Metabase.bin using xcopy, scopy, or any other copy routine. You should stop the Internet services first so that your metabase is up to date and not in use.

Finally, there are two scripts provided—metaback.vbs and metarest.vbs—which are located in Inetpub\IISSamples\sdk\admin (if you installed the IIS SDK on IIS 5.0) or in the IIS Resource Kit\Utility\ADSI Admin Scripts folder (if you installed the IIS 4.0 Resource Kit). These .vbs scripts use an ADSI command specifically provided to make metabase backups.

There are a number of tools available for this purpose. You will find there are quite a few commercial tools available that are fully equipped and can be useful. Microsoft provides the Web Application Stress Tool, which is sufficient in many cases for loading Web servers to see how well they perform when stressed. It's a good idea to test beforehand, as problems with application design may not be revealed until the server is under a load—and you wouldn't want to have to find this out on a production server.

The Web Application Stress Tool has several useful features, including the ability to record a playback script while you point and click your way through a Web site. You can then play back the script on one or numerous clients simultaneously while remotely monitoring performance-monitoring counters on the server. In addition, you can specify details such as user accounts to use for testing authentication throughput, as well as indicate delays between requests and testing schedules.

When you install the Web Application Stress Tool, it installs a service on the computer called WebTool. Be sure to uninstall the Web Application Stress Tool when it is no longer required.

The "Under Construction" page should appear any time you access the default Web site from a remote IP address. If you access it from a local IP address, the IIS online documentation should be displayed. If you access http://localhost in Internet Explorer, and you do not have Default.htm or Default.asp installed, the Web site will run IISStart.asp. IISStart.asp will check for two conditions:

In either event, you will be redirected to Localstart.asp which will then open the required pages.

Make sure these files are present on your system and that the Documents tab calls IISStart.asp. To make certain, try writing a brief .asp page that displays the values of the server variables, as follows:

Your local IP address is 157.54.120.171

The client IP address is 157.56.40.115

If the IP addresses are not identical, the Localstart.asp page will not be invoked. Of course, you can always call it directly using http://localhost/localstart.asp. You will have a problem invoking Localstart.asp directly if the there is no default document configured. The script will return the message:

You do not currently have a default document set for your users. Any users attempting to connect to this site are currently receiving an Under Construction page.

Windows XP Home Edition does not support any version of IIS and cannot be made to run IIS by any reliable method. Windows XP Home Edition was not designed to be a development platform for Web-based applications. Upgrading to Windows XP Professional will allow you to install IIS 5.1 on your system so you can develop with ASP.Net. IIS 5.1 on Windows XP Professional is a full-featured and capable Web server, but is limited to 10 simultaneous connections since it is a workstation operating system and not a server platform. There are also a few other limitations consistent with Windows XP Professional being used as a client operating system and not a server operating system. By and large, these are the same differences you find in IIS 5.0 on Windows 2000 Professional, and Windows 2000 Server or Advanced Server. Nevertheless, Windows XP Professional is an excellent environment for developing Web-based applications with the .NET Framework.

Programs written to work with a Web server have specific requirements. You can't, for example, invoke an instance of Notepad.exe from a URL and expect to see a Notepad window on the client system. In order for an executable (that is not CGI) to interact with requests from IIS, it needs to be written using ISAPI. ISAPI stands for Internet Server Application Programming Interface. There are two kinds of ISAPI executables: extensions and filters.

ISAPI extensions can be invoked directly from a URL such as http://localhost/myisapi.dll. Assuming you have IIS configured to permit scripts and executables on the directory and the user has the Execute NTFS permission, the dll will run. IIS allows you to specify if the application will run in process (as part of Inetinfo) or out of process (as part of MTX on IIS 4.0, or dllhost as part of IIS 5.x). When an application is run out of process, Inetinfo is insulated from problems. If the application fails, so does the Web server.

ISAPI filters are another matter altogether. ISAPI filters are able to modify the incoming and outgoing data stream to and from IIS. As a result they have a great deal of power and can be used to implement custom logging, authentication, or modify the data stream. Features implemented in ISAPI filters for IIS 5.0 include data compression, digest authentication, and URLScan.

Because filters play such a central role with IIS, they are, by design, always run in process as part of Inetinfo. Consequently, proper ISAPI filter construction is essential to server health. You may wish to work with Microsoft Product Support Services to identify the problem, as troubleshooting exceptions of this sort can be quite a challenge.

There are a couple of new technologies that may make life easier in this regard, and IIS 6.0 is one of them. Due to it's new architecture, all ISAPI filters run out of process. This will insulate the Web server from a wayward ISAPI filter, but does not actually solve the problem. Toward that end, consider what the .NET languages may be able to do in terms of ISAPI filters. Implementing equivalent functionality with .NET is simplified significantly over standard ISAPI Filter design with C++.

You're best bet for using WebDAV from scripts on IIS would be to use the WebClient class of ASP.Net. If you are using Windows XP or Windows Server 2003, WebDAV functionality is part of the operating system. This permits you to reference a file on a Web server using HTTP in the same way you would use a UNC pathname. For example, you could map a drive with NET USE * http://servername/directory and then access that location using the drive letter. Alternately, you can create a COM object that is a WebDAV client. You can use the object to issue WebDAV verbs to IIS 5.x or IIS 6.0.

Additionally, if you search MSDN for WebDAV, you will find several examples of how to use XML to craft WebDAV queries for Exchange and other Microsoft servers.

There is an excellent, free utility called Filemon that you can get from Sysinternals.com. You can quickly diagnose most permissions issues with Filemon as it will display in real time all files accessed on the server, the name of the calling process, and result of the access. Consequently, any "Access Denied" messages, regardless of how buried in nested includes or how obscure the temporary index, are easily identified.

It can be frustrating when an application that worked on one operating system has problems after upgrading. However, problems of this sort are often instructive as well. One of the differences in IIS 4.0 and IIS 5.0 has to do with the differences in COM and COM+. In IIS 5.0, when a COM+ object touches files on behalf of the user, its default behavior is to do so using the security context of the user. This was not the case in IIS 4.0. Consequently, when moving applications from IIS 4.0 to IIS 5.0 that involve COM, you may need to provide users permissions to files that were not required in IIS 4.0. While this is inconvenient in cases such as yours, it is certainly an improvement in the security design of the application. Even though you may not be using custom COM objects to access databases, COM is in widespread use in native IIS components.

One place where you see this requirement is in the need to grant users who are creating database requests permissions to temporary folders used by Access. For more information see Q210457 and Q271071 in the Microsoft Knowledge Base.

Before making any changes to IIS, the first step should always be to back up the metabase. For more information about backing up the metabase, read How to Create a Metabase Backup in IIS 5.

The IIS Lockdown Tool is an excellent utility. This tool allows you to easily and significantly increase the security on your server. Once you run the tool, it stores the history of its actions in a file located at %systemdrive%\%systemdir%\system32\inetsrv. You will find this information in the following files:

Oblt-undone.log may also be present.

If you remove these files, the wizard will start as if the IIS Lockdown tool has not been run. Because this procedure will allow you to run the Lockdown tool as if it had not been run, it does not "unlock," or reverse, the settings the Lockdown tool implemented when it was first run.

IIS 4.0 and IIS 5.0 offer this option without requiring you to modify all the files' extensions. The ASP processor will also process server-side include syntax so there is no need to use both .stm extensions and .asp extensions. So how does that help you? You can map your .htm files to be processed by asp.dll by creating an entry in the application configuration so that files with the .htm extension will be processed by asp.dll. This way, your includes contained in .htm will be processed without renaming your files.

Now you may be thinking: "Won't that cause all my .htm files to be processed as if they were scripts, thereby slowing down performance?" Indeed, this is the case in IIS 4.0; however, the performance hit may not be as great as you'd imagine in IIS 5.0 and the is even better with IIS 5.1. IIS 5.0 has a feature called "Scriptless ASP" to address this specific concern. If a file presented to the ASP processor contains no script, it is not parsed, but is instead simply delivered as a static page—a useful feature in this particular scenario.

Since IIS 4.0 was released well before Windows NT 4.0 Service Pack 6a (SP6a), be certain that you reapply SP6a and all hotfixes required after you install IIS 4.0.

The last thing you want to do is add domain users to the Power Users group, because this gives anyone with a user account on the domain elevated privileges on your system. If you trust every member of your domain to make good administrative choices for your system, then fine, but that is a level of trust that most computer users are not comfortable with.

To create a virtual directory in IIS, a user needs Administrator rights. This is by design since anyone who can create a virtual directory on a Web site, can also delete, rename, redirect, or otherwise manage all other virtual directories on a Web site.

Recognizing that you may wish to delegate authority without creating administrators, there is a feature (the Operators tab) in the IIS snap-in that allows you to designate a Web Site Operator (a non-administrator) to create virtual directories for a Web site. This feature is only available in Windows 2000 Server, Windows 2000 Advanced Server, and Windows 2000 Datacenter Server. The same feature also applies to IIS 4.0.

Additionally, you can create a virtual directory within an IIS Web site and map it to %systemroot%\%systemdir%\inetsrv\iisadmin. You will want to secure this virtual directory; otherwise anyone accessing the site will be able to manage the Web site. Note again that this is only available on Windows 2000 Server, Windows 2000 Advanced Server, and Windows 2000 Datacenter Server (and IIS 4.0).

When you find yourself giving extended permissions to others or otherwise working against the operating system limits trying to get your workstation to act as if it were a server, you probably need the features of a server operating system.

Let's review the problem of SSL and host headers because it is always in the top five of a FAQ for IIS.

When the client sends a request for an HTTP connection to the IIS server, the client request includes a field called HOST:, which contains the Web server requested in the URL. For example, if you requested http://www.microsoft.com as your destination, then your browser sends to the server, along with other information in the HTTP header, HOST: http://www.microsoft.com. Because the name of the field is "HOST" and it's in the client's HTTP header, it is referred to as the "host header."

If the client requests an SSL connection, the host header field is still included, but contained in the encrypted part of the packet (in the application layer), so it cannot be decrypted by the Web server in order to determine which Web site the request should be routed.

This creates an unbreakable rule: You cannot use Host Headers as the primary means of identifying a Web site when using SSL.

What happens if you do try to use SSL with host headers? Consider this configuration. You have two Web sites, one that does not use host headers and one that does. Both sites use the same IP address and both sites are configured with certificates. When you try to access the host header based site with SSL, the first Web site will respond. This occurs because it's the IP address that is used to identify the site you wish to use to make a connection, not the host headers. Since the first site responds to the IP address and HTTPS, it accepts the request. If the first Web site required host headers, was on a different IP address, or did not have a certificate, the connection would fail.

Therefore, regarding your configuration, do what you like as long as you don't use host headers on the same site that you require SSL.