Export (0) Print
Expand All

IIS Insider - July 2003

By Brett Hill

Another Way of Changing Passwords In IIS Through Internet Explorer

Q: We would like to use IIS as means to change passwords using Internet Explorer but have concerns about the .htr files that are used for this purpose. Does Microsoft have another way to change passwords that do not involve using the .htr mappings?

A: The .htr files you refer to are installed by default on IIS 5 and are indeed intended to provide a way for you to change passwords using Internet Explorer. This is an important function many web servers provide particularly when providing services such as Outlook Web Access where users can connect via the web to Exchange. The .htr files are mapped to ism.dll which provides the password changing functionality; however, this particular application mapping has had a checkered past, and so you are wise to have some concerns. The good news is that Microsoft has released an update to .htr/ism.dll programs. You can find the update for IIS 5 at http://www.microsoft.com/downloads/details.aspx?FamilyID=67d0d0f8-2978-4e7a-b079-346314bd2d5e&DisplayLang=en and for IIS 4 at http://www.microsoft.com/downloads/details.aspx?FamilyID=81cd9ed2-d1ff-425b-837d-a502ede956fe&DisplayLang=en. Also, this update is automatically applied as a part of Windows 2000 SP4.

The update is called HTR-2-ASP and replaces the .htr files with new files which are then mapped to asp.dll instead of ism.dll. The installation will make a backup of your existing .htr files that are typically located in winnt\system32\inetsrv\iisadmpwd.

Several things to be aware when configuring and installing this software:

  • If you have removed the mapping for .htr to ism.dll, or disabled it with the IIS Lockdown tool, the installer for the updates will refuse to run. You will need to recreate the mapping for the setup program to run. Examining the iisadmpwd folder, you will find that the scripts are still named .htr; however, if you check your application mappings, you will see that .htr file is now mapped to asp.dll instead of ism.dll.
  • By default on IIS 5, the iisadmpwd folder is not available on the web server and you will need to create a virtual directory mapped to the .htr files. Make certain to name the virtual directory IISADMPWD or the files will not run as written, as the directory name is coded into the script. Also, be certain that anonymous access is allowed or you run the risk of entering into an infinite loop as described in the Microsoft Knowledge Base article 275457.
  • You will need to have a certificate installed on the web site from which you intend to run the .htr files. This ensures that your submission from the form can be sent using SSL so the passwords are not sent clear across the network.

Once you've accomplished these steps, you can access the page http://<servnername>/iisadmpwd/anot.htr (for example) to bring up the form that permits you to change your password. There are some additional settings that affect the way IIS works with these capabilities. You will definitely want to read the Microsoft Knowledge Base article 267596.

Keep in mind that the .htr files provided by Microsoft are not intended to be a finished product (the updates). While they can be used as is, you will likely want to modify the scripts to better fit your web site. For example, by updating the asp code, you can enforce custom password policies, validation rules, logging and alerting functions - to name a few of the creative possibilities.

Default Web Site Content Overwritten When Publishing Multiple Sites

Q: I am attempting to run multiple web sites on one server using Windows 2000, Frontpage and Front Page extensions. My problem is that every time I publish a site, it writes the content to the Default Web Site. For example, when I first update the site Default Web Site at, everything works fine. When I then I publish my next site to, it overwrites the first content of site at

A: Check your configurations carefully. Make sure you don't have a blank entry in the Advanced tab of the setup where you make host header entries (unless you want the web site to use host headers). This kind of problem is 99.9999 percent of the time a misconfiguration of the IP addresses or host headers.

The answer to your second question is no. The host header site is exactly what you indicated in the host header field. If you put xyz.com in site A, and abc.com on site B then they respond to abc.com and xyz.com, respectively.

So, if your domain is blurt.com and your main IP address is and you want another host header web site, you can make a DNS entry for a host "test" that points to Then create a second web site that has the host header test.blurt.com. All requests to test.blurt.com will go to your new site, while all requests to blurt.com will go to non-host header web site.

Error Message: HTTP 403.6 - Forbidden: IP address rejected

Q: At work, when I try to view my web site from my computer on a 192.168.x.x network, I get a 403.6 error message stating Forbidden – IP address rejected. When I access the same site from a different computer on a different subnet, everything works fine. Do you have any suggestions?

A: When I encounter an atypical problem of this sort, my first suspicion is a configuration issue. Be certain that you have your setup properly configured the settings as it is easy to confuse the settings for Granted Access and Deny Access as shown:

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

This deny list allows all computers except for to access the system. A simple flip of Granted Access to Denied Access would possibly look like a deny list as you say, but would actually deny access to all IP except for

Also consider that you may have placed restrictions in the WWW Master Properties as well as on the Default Web Site. You can place an IP address restriction on any node in the Metabase including individual files. If you entered an restriction at the Master level, it wouldn't show in the user interface at the website level – but would still be enforced.

If you've done everything right, then there's something more serious, like a Metabase problem, causing this behavior. If that is so, then you have a couple of choices aside from restoring a backup copy of Metabase.bin. The characteristic of the Metabase is inheritance. If there is a problem with a setting in the Metabase - in some cases, you can correct the problem by deleting the property at the web site, folder, or file level. This can be done in the IIS snap-in. Go to the IP Address and Domain Name Restrictions window in WWW Master Properties. Make a change in the IP address restrictions. It doesn't matter what you enter here as we don't plan to actually apply the change. Click OK to see if the web site you modified comes up as a child override. This will happen if there are values set for the IP Address Access Restrictions on a web site, folder, or file. If so, then force the master properties down to remove the child properties by clicking OK again. Then, you can reset the master properties settings back to their proper settings, and make entries at the web site or directory level as you require.

Alternately, you may need to use Metaedit to examine the IP restriction list in the Metabase which is named as property number 6019 with the name IP Security (as shown).

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

If you find this key under the Root node of your web site, delete it. Of course, make a backup of your metabase first. Reset IIS and that should eliminate any orphan entries that could be interfering with your access.

How To Migrate and Troubleshoot FrontPage-enabled Sites (from IIS 5 to IIS 6)

Q: We moved our web sites from IIS 5 to IIS 6 and in the process moved from FrontPage Server Extensions 2000 to FrontPage Server Extensions 2002. People are experiencing authentication errors when they upload their sites from FrontPage. Are there any guidelines for migrating FPSE from IIS 5 to IIS 6?

A: As administrators of Front Page web sites know, Front Page Server Extensions can be challenging to administer, and migrating Front Page web sites can result in some needed adjustments. There are numerous possibilities and rather than list them all here, I'll refer you to the document Deploying FrontPage 2002 Server Extensions at http://www.microsoft.com/serviceproviders/whitepapers/fpse2002.asp. This document includes tips on migrating FrontPage web sites from IIS 5 to IIS 6 as well as troubleshooting techniques including the problem you've referenced.

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.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
© 2014 Microsoft