Enabling Script Access to IIS Virtual Directories

Exchange 2000 Server uses Microsoft IIS virtual directories to enable HTTP access. IIS lets you set various permissions on these virtual directories, which, in conjunction with NTFS permissions, determine the level of access users have to the content. Examples of IIS permissions are Read, Script Source Access, and Log Visits. In addition, you can set Execute Permissions on a virtual directory to enable or disable the ability to run scripts and executable files on the server. All details about these permissions are stored under various identifiers in the IIS metabase.

The following example helps explain how you use various components of IIS and Exchange System Manager (ESM) to enable access over the HTTP protocol to an Exchange 2000 Store. Suppose you want to create a separate Exchange 2000 public store to house the source code and data for a Web-based application. Follow these steps:

When you create the HTTP virtual directory in the Protocols container, the Exchange System Attendant automatically runs the Metabase Update utility, which ultimately creates an IIS virtual directory called Applications. At this point, if you were to go into Internet Services Manager (ISM), you would see the Applications virtual directory. The default Execute permissions on this virtual directory is None, so that no Active Server Pages (ASP) files can run.

Exchange 2000 stores all its configuration information in the Active Directory (AD) Configuration container, whereas IIS stores its configuration in the IIS metabase. In theory, the Metabase Update utility keeps the two sets of configuration information in sync so that administrators need to use only ESM. However, some IIS configuration settings aren’t accessible from ESM, and if you’re not careful, the next time Metabase Update runs, it can overwrite changes you make with ISM. The rule of thumb is to make changes with ISM only if you can’t make the same change with ESM (e.g., to set Log Visits).

One configuration option that needs special care is setting Execute permissions. You must set Execute permissions to Scripts or Scripts and Executables for ASP files to run successfully. In my example, I want to set the permission on the Applications virtual directory. ESM lets you set this permission only at the top level of the virtual directory; any subfolders automatically inherit the setting. You set this permission on the Access tab of the Properties dialog box for the virtual directory, as Web Figure A shows. If you require a finer level of control for any subfolders, then you must use ISM because it lets you drill down through the virtual directory. When you get to the subfolder you want, you look at its properties and set the Execute permissions there, as Web Figure B shows. Because the subfolders inherit these settings from parent folders, if you subsequently change the setting at the root through ESM and the Metabase Update utility runs, any subfolders whose settings you’ve changed through ISM are excluded from the global change.

This behavior has one exception. If you use ISM to make a global change at the root of the virtual directory, the next time Metabase Update runs, it will assume that no folders within the directory have had their settings changed and therefore will overwrite the current settings. In my example, if I had used ISM to set Script access to the Applications virtual directory, the next time Metabase Update ran, it would have reset all settings to None. This occurrence, of course, fits in with the rule of thumb because you can use ESM to set the root-folder access—and you should do so.

Last, the Metabase Update utility uses the source MSExchangeMU to log various events to the Windows 2000 event log. Web Figure C shows the event generated when I used ESM to set the access permission on the Applications virtual directory.