Key Links

IISTraining.com
hands-on, fast track, up-to-date training on IIS 5 and 6

IIS Lists
moderated email discussions on IIS related topics

IIS Boards
online IIS bulletin boards

About Brett Hill

Advertising Info
if you're interested in reaching thousands of IIS administrators.

Privacy Statement

IISAnswers Articles

A look at IIS 5.1 in XP Pro.
What's different from IIS 5?
(from the IIS Security and Administration coursebook)
by Brett Hill

Generally the same as IIS 5

IIS 5.1 is a feature only to be found on Microsoft's XP Pro operating system. It is not installable (reliably) on XP Home. Additionally, there are no plans to update IIS 5.0 on Windows 2000 to IIS 5.1.

IIS 5.1 is basically the same engine as IIS 5.0 but since XP is a client operating system, it has the built in limits that are customary for Microsoft’s client operating systems—such as connection limits and only one Web site. Even though based on IIS 5, there are significant differences from IIS 5.0 that you should know about.

Significant Differences

Some of the differences in IIS 5.1/Windows XP Pro are also features in common with .net Server. For example, the XP MMC snap-in has a similar design to the .net MMC in that there is a Web site Folder directly below the computer icon.

The WWW master properties are accessed by right clicking on the Web Site Folder and selecting “properties.” In IIS 5.0, the WWW master properties were accessed via properties on the computer icon.

The structure of the default Web site is different from IIS 5. The Script and MSADC virtual directories are absent. Most notably, there is a new virtual folder called tsweb that contains the Remote Desktop Sharing files. This folder points to c:\windows\web\tsweb where you can find the script that launches a Remote Desktop Sharing screen. Evidently, this is a variant of the Terminal Services Advanced Client.

ASP File Cache

The IIS 5.1 user interface for ASP settings contains a few more control settings than were found in IIS 5. The Cache Options property sheet is new in IIS 5.1.

These properties contain some settings that were formerly located on the IIS 5.0 Process Options sheet (see the IIS 5.0 Process Options screenshot a few paragraphs below):

However, I find the new page a bit confusing. Notice that when you enable Cache all requested ASP files that the ASP files cached in memory box becomes enabled. This doesn’t seem to make sense. After all, I just said that we wanted to cache ALL the files, so why am I now being asked how many files to cache, which is by definition, less than “all”.?

Now, I know they don’t just make this stuff up and that behind closed doors at Microsoft they actually wrangle and wrestle about this kind of stuff. Giving Microsoft the benefit of the doubt by taking a closer look reveals that Cache all requested ASP files relates to requested ASP files, while the second relates to ASP files cached in memory.

In other words, you can say “cache all requested ASP files to a folder and store 500 of them in memory.” It would be helpful if the label for ASP files cached in memory said something like “Maximum ASP files to cache in memory,” since otherwise we don’t know if this is a maximum, minimum, or default value. It would also be helpful if the help files associated with this topic actually explained the settings related to to this window instead of just referring to them.

We find a similar scenario with the Limit ASP files cached to: setting. This also has an accompanying ASP files cached in memory value, but this time it also has a handy slider to change the number. While helpful, it is curious why the second ASP files cached in memory merits a slider while the first one doesn’t. Furthermore, it is confusing that there are two values labeled ASP files cached in memory. Since the settings are mutually exclusive, only one value is required.

The Disk cache directory property is also new. This allows you to specify where you wish to place the ASP file cache. I don’t know why it isn’t named “ASP File Cache directory” instead of “Disk cache directory,” since that is name of the Box that contains all these values.

Even more interesting is the name of the folder that is used. Notice it ends in ASP Complied Templates. That is quite enlightening.

In reality, what is really going on here is that when an ASP file is requested, the file is not cached by IIS. Instead, it is complied into a “template” and placed in the designated “Disk cache directory.” The template is the “file” referred to. The question regarding the number of files to keep in memory is only slightly misleading as IIS does not cache any ASP files in memory, only templates and file handles for static files.

For your comparison, below is the IIS 5.0 Process Options property page.

IIS 5.0 Process Options screenshot

Authentication

IIS 5.1 does not include any new forms of authentication, but does have newly designed, and I think, improved layout for the authentication page.

This design allows you to specify all the details for authentication on the same page. In IIS 4.0 and 5.0 you have to click an additional Edit button to change the anonymous account or set the default domain for Basic authentication.

Note, however, that you can now also set the Realm for basic authentication from here. This is an interesting new capability for IIS, since this was not possible to designate in earlier versions in the user interface. A Basic authentication prompt includes a Realm text box that indicates the name of the Realm for which the user is requested access. This is not a Windows Networking feature, so it is not generally used in Microsoft networks.

However, you can set a default Realm value in IIS 4.0 and IIS 5.0 via the metabase property “Realm.” For example: adsutil set w3svc/Realm “IISanswsers.” See: http://www.microsoft.com/windows2000/en/advanced/iis/htm/asp/apro9ael.htm for details about the metabase property.

Using the Realm

The idea of a realm is to create a security boundary. Content in the realm can then be set to require authentication. If you access content in another realm, you must re-authenticate. For example, let’s presume you have an intranet site where anonymous access is not allowed. You have a folder for public content “Public_Content” which has permissions set to Everyone—Read and a Realm of “Public.” You also have a folder for Accounting called “Accounting_Content” that you want only members of the Accounting group to view. This folder has permissions of Accounting—Read and a Realm of “Accounting.” If you use Basic (or Digest) authentication, your accountants can read the Public folder, then, when they access the Accounting_Content folder, they will be prompted to Re-Authenticate, even though they have permissions to view the Accounting_Content folder and have already authenticated to the server. In this way you can force a logon and control security “zones.”

The following information can be found in the IIS 5.1 online docs under configuring Advanced Digest Authentication (which also uses realms).

It is possible to configure either one or multiple realm names on an IIS server. If multiple realm names are used, they must be configured at different levels of the metabase. You may want to configure multiple realm names for instance, to allow access to the sales virtual directory to members of domain1 and access to the engineering virtual directory to members of domain2. This is particularly useful if domain1 and domain2 do not have a trust relationship. See the online Windows XP documentation for more information about domains.

If a child node in the metabase is not configured with a realm name, that child node inherits the realm name from the next higher level that has the realm name configured. If the realm name is not configured, IIS sends its own machine name as the realm name. If IIS sends its own name as the realm name and IIS is not running on a Windows XP domain controller with Active Directory, Advanced Digest authentication will fail. Although possible, it is not recommended to run IIS on a Domain Controller due to security risks and performance issues.

You will need a good understanding of Realms to integrate with Unix products or products such as Tomcat java serverlets (http://jakarta.apache.org/tomcat/tomcat-4.0-doc/).

IIS 5.1 has one additional authentication feature called Advanced Digest Authentication. This is basically the same as Digest authentication in Windows 2000 but does not require that clear text passwords be stored in Active Directory. It is very unlikely you will use Advanced Digest authentication as the administrative configuration requires that you create and manage multiple metabase entries. In addition, at this time it is only compatible with IE 5.x or greater and IIS 5.1. There are other configuration details as well. Bottom line: by the time you get configured for Digest or Advanced Digest, you may as well be using Kerberos.

Metabase Backup and Restore

The metabase backup and restore functions have been enhanced in IIS 5.1. The online documentation states that you can import an XP metabase to a different computer, but exactly how to do that is not apparent from the user interface. My guess is you must move the backed up metabase file into the target systems \inetsrv\metaback folders since you cannot provide a pathname in the backup and restore feature.

The big news here is that the IIS 5.1 XP metabase is not keyed to the server. In fact, that “old” technique used by IIS 4 and IIS 5 that ties a metabase to the server is called a “legacy” backup in the help files. My, how time flies. Windows 2000 is now legacy.

The new Configuration Backup form presented when you select the Backup/Restore configuration allows you to encrypt the saved metabase with a provided password. To restore the backup, you must of course know the password or, according to the online docs, the backup is useless.

In addition to these goodies, there is a new feature called the Metabase Snapshot Writer that creates a “stable and reliable” backup of the metabase when NTBACKUP is used. It is only used with NTBACKUP and doesn’t have any other obvious purpose. The problem with this kind of a new feature is the implication that without it, as in IIS 4.0 and IIS 5.0, you may get an “unstable and unreliable” backup of the metabase when you use NTBACKUP. I have not heard of this, but evidently there was enough of a problem to cause Microsoft to want to create something new.

In the Followthrough Dept

IIS 5.1/XP has some interesting remnants that show its heritage and a little bit of housekeeping that needs to be done by the installation program.

For example, the ISAPI compression filter Compression.dll is installed, but you can’t turn on compression in XP. Additionally, the folder for compressed files \Windows\IIS Temporary Compressed Files is created, but is not used. The online help says this is supported, but I could not find where to enable it in the user interface.

The help files also state:

IIS 5.1 has Web-based administration tools that allow remote management of your server from almost any browser on any platform.

In IIS 4.0 and IIS 5.0, this lingo refers to the Administration Web site, which is absent on client operating systems such as XP. However, here they may be referring to the Remote Desktop Sharing virtual directory mentioned earlier. In any event, it would be very helpful if they more exactly named what they were referring to.

Also, there is a section on WebDAV and SSL, but the XP WebDAV redirector does not support SSL.

WebDAV Redirector

WebDAV is one of the features of Windows 2000 that is still largely unknown even by experienced administrators. Even among those who have some notion what it’s about, it remains underappreciated for its benefits and for the security issues it presents.

Windows 2000 is WebDAV enabled as a client if you publish to a Web Folder from the Desktop, Office Application, or Internet Explorer. You can’t however, use NotePad or Wordpad as those programs are not WebDAV enabled. In other words, the client software bears the responsibility of being WebDAV enabled.

Not so in XP. Everything in the OS can publish to a WebDAV enabled Web server such as IIS 5.0, IIS 5.1 or IIS 6. This is because XP contains a WebDAV network redirector thereby enabling non-WebDAV client software to open and save files to the Web server over HTTP.

This is a big deal.

You can now map a drive to a Web server so that when you save a file to drive X:, for example, it is published directly to a Web server. You can also select “file, open” and type http://servername/folder as a pathname just as you can a drive letter or UNC pathname.

However, there is some confusion in XP land. WebDAV is touted as being the preferred method for publishing content to a Web server, but when you use the WebDAV, network redirector cannot create a Web folder or map a path to “servername” only. In other words, http://servername will fail to successfully map. You will get a window, but it is computer icon next to \\localhost indicating the redirector returned to you a UNC pathname even though you clearly specified a URL. Your request for a web folder was completely ignored and you are given a connection to a folder using a different protocol than the one you requested. This seems like a bug to me.

If you specify a URL that ends with a folder name in the form http://servername/directory, then your web folder request is handled correctly.

What this means is that you cannot access the content in the root of a Web server using the XP WebDAV redirector. So, you can’t edit default.asp, global.asa or any other content that resides in the webroot using the new redirector.

Additionally, despite what the online documentation says about using WebDAV and SSL as a secure means to transfer files, the XP WebDAV redirector does not support SSL.

But now things get strange.

In Windows 2000, creating a Web folder to http://servername works just fine, as does using HTTPS to transfer files securely with a Web folder. In XP, you cannot create a Web folder using HTTPS from My Network Places—Add a Network Place. However if you use Internet Explorer, File, Open https://servername/folder and check Open as a Web folder, it will open as an HTTPS enabled Web folder and automatically create an HTTPS Web folder in My Network Places.

So, my guess is that we have a combo of Windows 2000 style WebDAV capability via Internet Explorer which allows us to use SSL on a Web folder, and XP style which does not. As a result, the exact steps you use to create the folder matter.

Why WebDAV Matters

Imagine that every XP operating system was also an FTP client such that any program you run on XP can use FTP to publish files to a Web server. Also imagine that all Microsoft IIS 5.x Web servers were automatically FTP enabled by default and you as an administrator could not prevent it from being installed or disable FTP from the user interface. Just substitute WebDAV for FTP and you should gain some appreciation for the situation.

Clearly this requires extra diligence on your part as an IIS Administrator managing WebDAV access to your servers. Controlling access to WebDAV is best managed with URLscan version 2. In Windows 2000 SP3, there is a new registry entry that will disable WebDAV access for the server.

Why the heck Microsoft doesn’t just place a checkbox in the IIS user interface to allow or deny WebDAV access to each site is a complete mystery. Instead administrators are forced to use administer registry entries and ISAPI filters such as URLscan to manage WebDAV security for Web servers. All of these techniques have been or are being recommended by Microsoft.

Connection Limits

XP Pro allows 10 connections. This limit is installed by default in the metabase key MaxConnections for W3SVC, and there is no user interface method for modifying the setting. You can change this setting to any number less than 40 and it works, but that is not widely advertised.

Programmatic Changes

CDONTS

CDONTS (Colloaborative Data Objects for NT Server) is a feature of NT and W2K that allows you to easily send mail from a web page using the SMTP server. The simplicity of the code and widespread availability of free scripts employing CDONTS has resulted in CDONTS being widely adopted.

Quite a surprise to many administrators to discover that IIS 5.1 does not support CDONTS as do IIS 4.0 and IIS 5.0. This has been replaced by CDOSYS which appears to have more capability, but it is not quite as simple to use. See: http://support.microsoft.com/default.aspx?scid=kb;EN-US;q195683 for more details.

CDOSYS is supported by Windows 2000, so you can develop code in IIS 5.0 that works on IIS 5.1 and IIS 6.0. But if you are relying on CDONTS to send email, and many, many sites are; you ought to update your code.

You can enable CDONTS on XP by copying CDONTS.DLL from a Windows 2000 installation to your XP system’s Windows\System32 folder (default name). Then at command prompt Windows\System32 run REGSRV32 CDONTS.DLL. The extent of my testing on this was to deliver one piece of mail, so this should not be construed as a complete analysis of the effectiveness of this technique.

VBSCRIPT

XP ships with VBScript 5.6 which evidently has problem with code written in VBScript 5.5. That doesn't quite make sense, as they should be syntax compatible, but nevertheless there is a compatibility tool you can download which should help. See http://support.microsoft.com/default.aspx?scid=kb;EN-US;q310407 for details.

This is something that may actually be a showstopper in terms of using XP as a development platform and details are very sketchy. This article will be updated as I find out more.

Summary

Overall, with the exception of the confusion about WebDAV, I like the changes in IIS 5.1 and wish Microsoft would offer an upgrade to IIS 5.0. If you are thinking about using XP as a client for Web development, you are thinking in the right directions, but watch out for the little things like CDONTs being absent and a different default directory structure than in IIS 5.