IIS Insider - April 2002

By Brett Hill

Processing Server Side Include Syntax Without Renaming Files

Q: We are planning to introduce server side includes in our intranet environment. This means we have to rename all our pages from .htm to .stm etc. I know that on Apache Web Server it is possible to modify settings so that .htm behaves as .stm pages so there is no need to rename the extensions. Is this possible on IIS? I had come across an older article (IIS3) on MSKB which explained how you could modify registry settings so that .htm will be treated as .stm files. However, I could not find an article that would make this possible on W2K/IIS5. Modifying the extensions is the last thing my manager is willing to accept.

A: Yes, you can do this in IIS 4 and IIS 5. 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 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?" I'm glad you asked. Indeed, this is the case in IIS 4; however, the performance hit may not be as great as you'd imagine in IIS 5 and the news is even better with IIS 5. IIS 5 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. That's quite a useful feature in this particular scenario.

Managing Permissions Manually Instead of Using FrontPage Client

Q: Our current server is NT 4.0/IIS 4.0 with FPSE 20000. We have an Intranet Site for a large department and security is applied via FrontPage by using sub-webs. To access a sub-web, we define a web folder and can access that folder via FrontPage. We use frames to make sure that the top of the page and left side of the page is only updated by webmaster.

I need to re-engineer the site. I don't know if it is better to use sub-webs to secure site as above and use frames - or should I use NT and IIS to apply security? If I use NT and IIS, I can use cascading style sheets and include pages. This would mean we would not need to have individual web sites inside each other (sub-webs) which would help out a great deal.

If I use NT and IIS for security - how does the author create their web folder? Do they map to the drive?

A: Since I'm not familiar with all the details of your situation, I cannot advise you as to which way would be best, but we can discuss the issues.

First, let's be clear in that it's not a matter of using FrontPage versus Windows NT security. In all situations, you are using IIS permissions and Windows NT authentication combined with NTFS. What you mean, I think, is that instead of using the FrontPage client to manage IIS and Windows NT security, you would manage permissions manually at the server.

You can disable the FrontPage client's ability to manage web server security by setting the "Manage Permissions Manually" checkbox on the FrontPage property sheet of the WWW Master Properties.

There is no problem with doing this presuming you know what you are doing with the permissions. Your best reference for configuring and managing permissions on a server with FrontPage Server Extensions is the FrontPage 2000 Extensions Resource Kit, located at http://officeupdate.microsoft.com/frontpage/wpp/serk/.

My personal bias is that, at the point where the sub-web design becomes difficult to secure, you need to reorganize. Sub-web's are actually just directories within a single web site - an "administrative unit" as far as the FrontPage client is concerned. Administration and security of the sub-webs can get complex and when large installations are involved. You may want to consider a different web site for each sub-web where you have clear administrative and security boundaries.

To answer your question in regards to mapping to a folder - the answer is no. Instead, just use HTTP with FrontPage as the client or use WebFolders to transfer content.

Accessing IISADMIN Virtual Directory Results in Server Reboots (IIS 4)

Q: I'm currently running NT4 sp6a and have just installed IIS 4. I believe it is setup correctly as I have not changed any default settings. When I access the IISADMIN virtual directory of the default web site through a browser on the server it behaves but when I access the same location from a client workstation the server crashes and reboots.

A: Well, that simply won't do. Since IIS 4 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.

Can You Allow Domain Users to Manage Virtual Directories in Windows 2000 Professional?

Q: I am running IIS (PWS) in Win2k professional which is in a Windows NT 4 domain. If logged on as Administrator, I am able to create virtual directories. I have added the Domain Users group to the Power Users group on the computer and also given Power Users the Full Control permission to the InetPub & subfolders. Nevertheless, only an administrator is able to manage IIS. I want domain users to be able to create and manage virtual directories of their own. Is there any solution?

A: Ok, let's start from the top. First, on a Windows 2000 Professional workstation, IIS is called IIS 5, not PWS (Personal Web Server). Since there are several versions of IIS and they have different capabilities, it is very helpful to use the correct names.

Second, adding Domain Users to the Power Users group is probably not a good idea. 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 level of trust that most computer users are not comfortable with.

Third, to create a virtual directory in IIS, a user needs Administrative 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 Data Center. The same feature also applies to IIS 4.

Additionally, you can create a virtual directory within an IIS website 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. The bad news is that, again, this is only available on Windows 2000 Server, Windows 2000 Advanced Server and Windows 2000 Data Center (and IIS 4).

My advice to you and others in a similar situation is that when 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.

Can You Use Host Headers On The Same Site Requiring SSL?

Q: I have a question regarding IIS and Host Headers vs separate IP addresses. We currently operate 2 separate web sites on 2 NT servers, one is an http://site and the other is an https://site. We have purchased a new server and it is running Windows 2000. We are trying to decide how we should operate both sites from this one new server. Should we use Host Headers and 1 IP address or use 2 separate IP addresses? I found Q187504 regarding problems in using Host Headers with IIS 5.0 and SSL, but it sounded like if you used the same IP address but different port numbers then this method can be used, I was a little confused on whether they were then actually recommending the use of SSL and Host Headers together or not?

A: Let's review the problem of SSL and Host Headers because it is always in the top five of an FAQ for IIS.

When the client sends a request for a 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. I don't care what else you've heard, this is the case.

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 website 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.

Submit your questions to 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.