IIS Insider - May 2004

By Brett Hill

Exporting a Web Site's Configuration to a File

Q: We are using IIS Manager to export a web site's configuration to a file. That is working fine and we can view the resulting XML file. However, when we go to import the file to another server, the web site fails to work. According to Microsoft, the IIS 6 metabase is supposed to be portable to another computer, so what are we missing?

A: One of the primary improvements in IIS 6 is that XML Metabase is much easier to manage than in IIS 5 binary Metabase. However, by default, when you export a web site with the IIS Manager, the exported Metabase can contain certain keys, such as the IUSR and IWAM passwords, that are encrypted with the local machine keys. As a result, if you import those settings to another server, those keys cannot be decrypted successfully by the target server.

The solution is to provide a password when you export the web site (as shown in Figure 1):

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

Figure 1   Exporting a Web Site's Configuration to a File

This form is displayed when you select the web site you want to export in the IIS Manager and select All Tasks, Save Configuration to File. In this case, the secured keys are encrypted with the password you provide rather than the machine keys. You can then import the Metabase on the target server by providing the password and the "secrets" are correctly decrypted.

Even so, you will still need to update information contained in the imported web site configuration that is unique to the source server such as the anonymous user, IP addresses, or file paths referenced by virtual directories.

Therefore, the "Encrypt configuration using password" option in the above form can also be thought of as "Make Portable."

Basic Authentication Tokens Are Cached

Q: We have noticed that user's can still log on to our site after they have been denied access. Eventually, they are denied access, but we'd like to find out why this occurs so that access is denied more timely.

A: This issue typically arises when using Basic Authentication parameters on an IIS web site. When the user authenticates to the site, they receive a "token" that is used for subsequent requests for access. However, to prevent the client's system from having to authenticate with every single request to the IIS server, which can really slow things down, IIS caches the token for a period of 15 minutes. This is a configurable parameter that can be set with the UserTokenTTL registry setting. This setting is set to the number of seconds the token should be cached. You can reduce or increase this setting in the registry at:


according to your requirements. This particular setting is only enforced with Basic authentication. Integrated Windows authentication tokens are not cached.

Which IIS 5 Caches Are Still Operative in IIS 6?

Q: In IIS 6, the http.sys listener has a kernel mode cache. In IIS 5, this cache wasn't present but IIS had its own caching built in. Is the caching that was in IIS 5 still present in IIS 6 or has it been replaced by http.sys? If it is still present, how do these caches interact?

A: Http.sys, the kernel mode http listener for IIS 6 is found only on Windows Server 2003. It does have a response cache built in so that content can be delivered directly from the kernel mode cache. The kernel mode cache is very fast and requires less overhead from the server; so by making effective use of the cache, you can greatly increase throughput while at the same time reducing load on the server.

As you mentioned, IIS 5 did not have this capability, but did have its own cache (several caches actually, but for simplicity sake, we'll talk about them as one). These are still present in IIS 6 and still help to increase performance even though the http.sys cache is present because not all content can be cached by the kernel mode cache. For example, content requested by authenticated users will not be cached by http.sys, but will be cached by the IIS 6 "user mode" cache.

Therefore, the short answer to your question is yes, the user mode caches found in IIS 5 are still present and operative in IIS 6. The second question about how these two interact is a bit more complex. The two caches do not directly interact in that one does not communicate directly with the other about what is or is not being cached. However, there are some configurable elements in your script and on the server you should be aware of to optimally tune cache performance.

There is an excellent document on this subject at titled Web and Application Server Infrastructure - Performance and Scalability. I would highly suggest a close reading.

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.