When you install IIS 5.0 on Win2K Pro, the Internet Services Manager menu item doesn't even load onto the Administrative Tools menu (as it does under Win2K Server). You must create a Microsoft Management Console (MMC) console and load the Internet Information Services snap-in (i.e., iis.msc) from \%systemroot%\system32\inetsrv. You can, however, use the Personal Web Manager (which you access from the Administrative Tools menu) to administer IIS 5.0 under Win2K Pro.
Another word of warning regarding IIS 5.0 and Win2K Pro: Many developers are creating complex systems that work fine on PWS or IIS 5.0 under Win2K Pro. However, after the developers migrate these systems to the Win2K Server environment, they experience difficulties with ODBC, permissions, ASP, and other environmental aspects. I get questions such as, "My application works fine on Win95 PWS, so what's wrong with Win2K Server?" My response is, "What's wrong with your development process if you're developing applications in an environment they aren't designed for?" Of course, writing code on a system that is compatible with the expected target environment is acceptable, but that kind of development process must include a transition phase. In a move from a workstation environment to a server environment, you can expect to encounter some differences.
When a user contacts an IIS server and requests a Web page, the IIS server reveals its IP address in the HTTP conversation between the Web server and the user. For security reasons, my company goes to great lengths to keep internal network addresses invisible. Can I change this IIS behavior?
In some cases—but not all—IIS returns the IP address. The Microsoft article "Internet Information Server Returns IP Address in HTTP Header (Content-Location)," http://support.microsoft.com/support/ kb/articles/q218/1/80.asp, states that IIS exposes the IP address only when you deliver static HTML content. In that event, IIS delivers a response such as what Figure 1 shows.
In this response, you can clearly see the server's internal IP address. To change this behavior, you can add an entry to the metabase. In the \winnt\system32\inetsrv\adminsamples directory, type
adsutil set w3svc/UseHostName True
at a command prompt. Then, press Enter. This procedure adds the necessary entry to the metabase. Be sure to back up the metabase before the modification, and stop and start the Web server afterward. (This modification works on IIS 5.0 and IIS 4.0.) Instead of the previous response, IIS will return the response that Figure 2 shows.
I installed IIS 5.0 on my company's Win2K Server machine. Now, users can't change their passwords over the intranet, as they could under IIS 4.0. How can I regain this capability, which is important in the company's installation?
A clean installation of IIS 5.0 gives you the ability to change passwords, but because of the security risk involved with users changing account passwords over your intranet or the Internet, IIS 5.0 doesn't enable the feature by default (as IIS 4.0 does). To enable this capability, you need to create an IISADMPWD virtual folder and add a metabase entry. (If you're upgrading from IIS 4.0 to IIS 5.0, you won't need to perform these steps.) Before you make any changes, you should stop and start the Web service and back up the metabase.
First, select the Web site you want to contain the virtual directory that will point to the IIS-installed programs permitting users to change passwords. For example, you can use the Default Web Site, which IIS 4.0 uses. Second, to make the change to the metabase, in the \winnt\system32\inetsrv\adminsamples directory, type
adsutil set w3svc/1/PasswordChangeFlags 1
at a command prompt. Then, press Enter. Users should now be able to change their passwords. For more information about virtual directories and clean IIS 5.0 installation, see the Microsoft article "IISADMPWD Virtual Directory Is Not Created During Clean Install of IIS 5.0" (http://support.microsoft.com/support/kb/ articles/q269/0/82.asp).
End of Article
Register
