IIS Informant - 19 Nov 1999

I'm trying to create a Web page on an IIS 4.0 Service Pack 5 (SP5) server in which users can download files through Microsoft Internet Explorer (IE) 5.0 browsers. Currently, the link points to an .exe file, but when users click the file, the session times out. I want to set up the system so that when users click the file, a pop-up box appears asking them whether they want to download the file or open it at the file's current location. How can I achieve this setup?

The timeout behavior you describe occurs when the Web server (or the directory that contains the .exe file) has Execute permission. When users click the .exe file, IIS attempts to run the file instead of downloading it to the browser. Because the .exe file isn't set up to communicate with IIS, IIS does nothing, so the session eventually times out.

To fix this problem, set your Web server's permissions to None or Script. The pop-up box you want will then appear.

I host a small intranet on a server running IIS. I installed and set up DNS, but I can't access the Web server by name. Do you have any suggestions?

You have two options. If you have a small LAN and the Web server's IP address is static, you can use a HOSTS file instead of DNS. The disadvantage of using a HOSTS file is that you need to install the file on every client, so setting up name resolution this way is harder than using DNS. However, the advantage of using the HOSTS file is that this file is faster than DNS, and you don't have to rely on the DNS server to gain access to the Web server. In other words, you eliminate one potential area for a single point of failure.

Alternatively, you can use the IIS Host Helper Service utility that comes with the Microsoft Windows Internet Information Server Resource Kit. This utility obtains the host names of all the virtual sites on an IIS machine and registers those names with NetBIOS on the local machine. Thus, the Web sites that IIS hosts are available through traditional Microsoft-style name resolution, without the need for DNS, HOSTS files, or static mappings for WINS servers. Because the utility registers the names with NetBIOS, the IIS Host Helper Service dynamically adds the names to the WINS server, without any special setup. Having the host names on the WINS server facilitates locating the Web sites across subnets. Even if you don't use WINS, the IIS Host Helper Service lets Microsoft OSs find the virtual Web sites through broadcasts.

The IIS Host Helper Service runs as a service. Here's how you install it:

1. Copy iishostsvc.exe to the \%systemroot%\system32\inetsrv directory.
2. Change to the \%systemroot%\system32\inetsrv directory, and type the command

   iishostsvc install

I set up several virtual directories on my FTP server. However, users can't see them. I rechecked the setup, and it seems correct. Do you have any ideas about what the problem might be?

Microsoft FTP servers don't list virtual directories on clients. Microsoft doesn't exactly advertise this FTP quirk, so administrators are often surprised to find out about it. You can access the invisible virtual directory if you explicitly reference it by name, but you can't point and click your way to it in the FTP client.

For example, suppose you have an FTP server pointing to the folder FTProot. In FTProot, you create a virtual directory called Articles. You set up Articles to refer to the folder C:\articles, which contains a dozen documents. When you use an FTP client to access the server, you expect to see a folder for the Articles virtual directory, but instead, you don't see anything.

You can apply a workaround to this problem. Create an empty nonvirtual folder in FTProot that has the same name as the virtual directory (in this case, Articles). The Articles folder will appear on the client. If you click this dummy folder, an amazing event occurs—the client lists the contents of the Articles virtual directory. Creating dummy folders is a handy way to display the contents of invisible virtual directories. However, don't place any files in the dummy Articles folder. The FTP client won't see any files in that folder as long as you have a virtual directory with the same name. For more information about this workaround, see the Microsoft article "Virtual Directories Not Visible on FTP Clients Due to Confirmed Problem" (http://support.microsoft.com/ support/serviceware/iis/ iis40/e9zqcaxap.asp).

Another FTP quirk you might encounter with virtual directories is that, in some circumstances, you can upload files but not retrieve them. This problem occurs with FTP servers that use a Uniform Naming Convention (UNC) pathname to map the virtual directory. When an FTP server uses a UNC pathname to map the virtual directory to the physical directory, the Internet Service Manager (ISM) prompts you for the credentials that you want to create the connection with. When you upload your files through FTP to the virtual directory, IIS uses those credentials to authenticate the connection. No problem results until you try to retrieve the same files. On retrieval, the FTP server doesn't use the credentials you provided for the virtual directory but rather those of the logged-on user (typically IUSR_). Unless that account is valid for the virtual directory in question, the FTP server denies you access to the file you just successfully uploaded. The Microsoft article "FTP GET Does Not Work Correctly on UNC Virtual Directories" (http://support.microsoft.com/support/kb/articles/q237/9/87.asp) discusses this problem and tells you to contact Microsoft Product Support Services (PSS) for the fix. The fix involves installing a new .dll file. Table 1 shows the file's attributes. SP5 also contains the fix. This .dll file's version number is 4.02.0682.04.

I've heard that Windows 2000 (Win2K) will feature new logon authentication methods. Will the version of IIS that comes with Win2K (i.e., IIS 5.0) feature a new way for users to log on?

Yes, you'll see changes in IIS 5.0 authentication. With IIS 4.0, you can use the Anonymous, Basic, or NT Challenge/Response method. With IIS 5.0, you can use the Anonymous, Basic, Integrated Windows Authentication, Digest, or Fortezza method.

Integrated Windows Authentication is Microsoft's new name for NT Challenge/Response. However, Microsoft is changing only the name—this authentication method still has the same benefits and shortcomings as before.

Digest is a new authentication method. Unlike NT Challenge/Response, you can use Digest across a proxy service or firewall. However, some trade-offs exist. Digest requires a Win2K domain controller as the server and IE 5.0 as the client. In addition, the Win2K domain controller must have a plaintext password list, which means that you must manually maintain a list of users and passwords. More important, a plaintext password list means the server needs a full-time security guard.

Fortezza is another new authentication method. This method requires that you obtain, for each client, a smart card reader and a smart card containing a client key and certificate. Consequently, Fortezza isn't likely to be in widespread use for a long while. However, if you have a high-security environment in which each workstation must be a secure intranet access point, Fortezza might be worth researching.

I recently moved a functioning Active Server Pages (ASP) application from a single-processor PC to a multiprocessor system. Now the ASP application doesn't work. The two systems are identical in software configuration; they differ only in their motherboards. I'm using Windows NT 4.0 with SP5 and Microsoft Access databases. How can I get the ASP application to work?

IIS 4.0 sometimes has problems running ASP applications on multiprocessor systems. In a Microsoft-hosted TechNet chat with IIS gurus, a Microsoft technician said in no uncertain terms that you'll run into multithread problems with the Access driver (http://www.microsoft.com/technet/chats/trans/iis714.htm). Microsoft hasn't published a hotfix for the multithread problems, but you can get a patch from Microsoft PSS. However, a couple of administrators told me that the patch didn't help them.

If the patch doesn't work for you, you can either remove one of the processors or migrate from Access to Microsoft SQL Server. Microsoft strongly recommends using SQL Server instead of Access in situations in which you need high performance and scalability. (For more information about Access vs. SQL Server, see the Microsoft article "ACC97: Using Microsoft Jet with IIS" at http://support.microsoft.com/ support/kb/articles/q222/1/35.asp.)

I have about 100 Web sites on several IIS machines. I occasionally update those Web sites with new virtual directory settings that are common to all the Web sites. How can I create batch files that automatically enter the updates?

You can automate this task with Microsoft Active Directory Service Interfaces (ADSI) scripts. ADSI lets you access IIS administrative objects. In addition, because IIS's HTML-based administration is based on ADSI technology, you can use ADSI with ASP to directly query and modify any IIS-related setting in the metabase.

You can download the latest version of ADSI at http://www.microsoft.com/ windows/server/technical/ directory/adsilinks.asp. This site also contains links to various ADSI resources and documentation.

The IIS resource kit contains example ADSI scripts, one of which is CreateWebVirtualDir.vbs. This script's function is to create virtual directories. If you have Windows Scripting Host (WSH), you can execute this VBScript file from a DOS command prompt. (You can also execute the script in an ASP file within IIS.) The syntax to execute this script is

Createwebvirtualdir <domain or hostname>
<virtual_web_site_name>
<new_virtual_directory_name>
<new_virtual_directory_location>

where you specify the appropriate information in each set of angle brackets. For example, if you type

Createwebvirtualdir localhost Scripts_R_Us
Newstuff C:\inetpub\wwwroot\scriptsrus\newstuff

at the command prompt, you create the Newstuff virtual directory on the Scripts_R_Us virtual Web site at the specified path.

One important note about using CreateWebVirtualDir.vbs is that the virtual Web site name is case-sensitive. You must type exactly what the Web Site Identification-Description field specifies on the Web Site Properties page.

CreateWebVirtualDir.vbs works well if you have one Web site. If you have 100 Web sites, a better alternative is to use the script Replicate_VD.vbs, which automatically identifies the case-sensitive virtual Web site names and creates the virtual directories. I created this script by modifying CreateWebVirtualDir.vbs to loop through all the Web sites instead of searching for a specific site.

You can find Replicate_VD.vbs on the IIS Administrator Web site. Go to http://www.winntmag.com/newsletter/iis, and access the online version of this column. In the Article Info box, click the .zip file under the heading Files/Code.

Explaining how this script works is beyond the scope of this column. However, many resources are available to help you learn how ADSI works in Web applications, including

• Christopher Furlin, "Working with ADSI" (http://www.microsoft.com/technet/iis). This TechNet series introduces readers to using ADSI in IIS applications.
• Steven Hahn, ADSI ASP Programmer's Reference, Wrox Press, 1998 (http://www.wrox.com/consumer/store/details.asp?isbn=186100169x). This book discusses how to use ADSI to create Web pages.

Is installing IIS on an NT workstation a viable option?

If you install the NT 4.0 Option Pack on an NT or Windows 9x workstation, you don't receive the full version of IIS but rather a scaled-down version called Personal Web Server. PWS offers many of the same capabilities as IIS. (On Win9x, you get the same PWS features, except for NTFS permissions and logon security.) However, PWS has some limitations, such as IP restrictions and a 10-connection limit. For more information about the differences between IIS and PWS, go to http://www.microsoft.com/ ntworkstation/eval/scenarios/ ntintranet/peerweb.asp.

PWS works well for designing Web pages. You can use PWS to develop ASP applications, then migrate those applications to a production server.

How can I set up IIS to run Common Gateway Interface (CGI) applications?

You can run CGI or other scripting language applications from IIS. However, keep in mind that when you use CGI, IIS creates a separate process for every client request, which can seriously affect your system's performance and scalability. Instead of using CGI, you might consider converting your CGI application to an Internet Server API (ISAPI) or ASP application because ISAPI and ASP applications run much faster than CGI applications.

If you run CGI applications, you need a Win32-compatible script interpreter. Popular script interpreters include

• ActiveState Tool's Perl interpreter (http://www.activestate.com)
• Tcl/Tk Consortium's Tcl interpreter (http://www.tclconsortium.org)
• Python's Python interpreter (http://www.python.org)
• IBM's Object REXX interpreter (http://www.software.ibm.com/ad/obj-rexx)

The ActiveState site offers several Perl interpreter packages. I recommend the free ActivePerl package. ActivePerl includes Perl for Win32, Perl of ISAPI (requires Perl for Win32), PerlScript (an ActiveX scripting host), and Perl Package Manager. Running Perl as an ISAPI application has many benefits, including increased speed and better scaling.

According to the ActivePerl instructions, the installation program handles a lot of the installation details for you. However, I had to manually install it on my site because the installation program didn't set up IIS to use Perl, even though the program extracted the files to the server. If you have to install Perl manually, as I did, use the following steps as a guide. These instructions are for installing only the Perl for Win32 (perl.exe) interpreter. You might also want to install the Perl of ISAPI for performance considerations.

1. Install the interpreter on your hard disk (e.g., C:\Perl).
2. Using ISM, select the Virtual Web Site that you want to run scripts from. Any change you make here applies to the site's contents. If you want to change information for a specific directory within the virtual Web site, expand the Web site, and select that directory.
3. Select the Home Directory tab (or the Virtual Directory tab if you're editing a virtual directory).
4. Because you'll run perl.exe from IIS, specify Execute permission. Don't also specify Write permission. If you specify both Execute and Write permissions, users might be able to upload and execute anything they want.
5. Click Configuration. If Configuration is unavailable (i.e., grayed out), click Create, then Configuration. You'll see the App Mappings tab, which includes a list of application mappings, which Screen 1, page 8, shows.
6. Click Add on the App Mappings tab. Type the path to the interpreter in the Executable box. Screen 2, page 8, shows a typical path. Type .cgi in the Extension box. Make sure that the Method exclusions and Script engine boxes are empty. (If you select the Script engine check box, a script interpreter can run from a directory that doesn't have Execute permission. Because, in this example, you're running perl.exe, you can't use this feature.) Whether you select the Check that file exists check box depends on your situation. Selecting this option ensures that a file exists when a CGI program calls it, but this option slows performance.
7. Repeat step 6 for each file extension you want to process through the interpreter. For example, you need to repeat this step if you want to run .pl files.
8. Click OK.
9. Set the NTFS permissions you want to use for the newly installed software. Giving the group Everyone standard Read permission is a good place to start for the perl.exe folder. Because the Perl interpreter is an .exe file, you need Execute permission. (NTFS Read permission includes Execute permission.) For tighter security, you can assign only NTFS Execute Special permission.
10. Set the permissions for the folders that contain scripts. Assigning Everyone NTFS standard or Special Read permission is a good place to start. However, for development, you'll also want Write permission for the script folders.
11. Set Write permission for any data folders you want to write to. Once again, don't use both Write and Execute permissions on the same folder.

Running CGI applications on IIS is a complex topic, and these steps are only a guide. The specifics of your situation might require other options and settings. For more information about this topic, see

• Leonid Braginski and Matt Powell, "Chapter 4, Web Server Configuration," Running Microsoft Internet Information Server, Microsoft Press, 1998 (http://mspress.microsoft.com/books/1270.htm)
• Megan Davis, "Migrating CGI Applications to IIS: Choosing an Approach" (http://www.microsoft.com/technet/iis/appmig.htm)
• Joe Barnes, "Running CGI Programs on IIS 4.0" (http://technet.microsoft.com/cdonline/content/complete/ internet/server/iis/tips/runcgi.htm)
• ActiveState's FAQs (http://www.activestate.com/support/faqs/default.htm).