Global Web Sites Properties Tabs

Many of the options that are set on an individual web site can also be set on a global basis so that they apply to all web sites on this server. Right-click the Web Sites folder in the left pane of the MMC, and choose Properties to access the Properties window. At the global level, all the same tabs appear in this window, with one addition: Service. If you change a setting on one of these tabs, it applies to all web sites, and some settings can’t be made at the global level.

The Service Tab

The Service tab, shown in Figure 2-21, includes the options for setting IIS isolation mode and setting HTTP compression.

Figure 2-21: The Service tab

Isolation Mode

IIS 5.0 isolation mode allows for backward compatibility with applications that don’t work under worker process isolation. These types of applications are rare, but IIS does support them in this mode. Here are some reasons why you’d need to use IIS 5.0 isolation mode:

• Multi-instance ISAPIs that are written to be used multiple times simultaneously by different processes.

• Read raw data filters that would try to grab all the data before it hits a web site.

• In-process session-state variables, because they are lost every time a worker process is recycled. If you’re using ASP.NET, this issue doesn’t exist.

• Applications that farm out work to their own worker processes.

Because isolation mode is applied at the global level, it applies to all web sites on this server. Therefore, if you enable isolation mode, you lose all the cool functionality that worker process recycling gives you. If you absolutely must use a certain application that doesn’t play well with worker process isolation mode, you may want to consider putting it on a web server by itself, so your other web sites can take advantage of this.

HTTP Compression

Most of you have probably experienced the excruciatingly slow web surfing experience of a 56K modem. You can have the biggest, baddest web server around with dual DS3 lines plugged in, but typically the weakest link in the chain leads to the client’s browser— this is what’s known as the “last mile,” or the copper in between the telephone company’s distribution point and the end user’s computer. There’s not a whole lot you can do about that, but you can enable HTTP compression.

HTTP compression is supported through the HTTP content-encoding standard. Most HTTP 1.1–compliant browsers support content encoding. When compression is enabled, IIS sends compressed files to the client. Note that this is different from compressing the data stream. With IIS compression, the headers are still uncompressed; just the files are compressed. The files are then decompressed by the client and interpreted by the browser.

Note 

HTTP compression takes extra CPU cycles on both the client and the server, because the content has to be compressed by the server and then decompressed by the client. This shouldn’t affect the actual performance, though. Needless to say, CPU time is generally not the limiting factor on the server, and especially not on the client.

These compressed files have a content expiration date of January 1, 1997, which prevents proxy servers and browsers from caching these files. This can be a downside to compressing files, since the cache on proxy servers and browsers speeds up the overall speed of browsing on frequently visited sites. When HTTP compression is enabled, after IIS receives a request, it goes through this process to get data to the client:

1. IIS checks to see whether the browser supports compression.

2. If it doesn’t support compression, the data is sent normally.

If it does support compression, IIS checks the type of file being requested to see whether it is static or application content.

• If the file is a dynamic-content file, IIS compresses the file and sends it. Dynamic files are not stored in the temporary compression directory.

• If the file is a static-content file, IIS checks to see whether the file is stored in the temporary compression directory.

• If the file exists in the temporary compression directory, the file is sent from there.

• If the file does not exist in the temporary compression directory, IIS sends the client an uncompressed file, and then compresses the file to the temporary compression directory for the next user.

Compress Application Files When you choose this option, all application content files are compressed before being sent across the wire. This includes ASP, CGI, and executables. Even though scripting content, such as ASP, is just regular HTML when it is sent to the client, it is differentiated from static content because of the processing that occurs on the server side. Because the response is compressed every time it is requested, it pretty much throws the whole ASP caching thing out the window. Caching dynamic content files has a much greater impact on system performance than caching static content files, because dynamic files are not cached to the temporary compression directory. To compress application files, you have to enable compression on static files as well. Although, interestingly enough, the GUI will let you do this without any prompting or error messages, it just doesn’t work.

Compress Static Files Selecting this option will configure IIS to compress all static files. The static files are stored in the temporary directory and served up to the client when requested. When a client requests a file, and compression is enabled for that file type, the file is sent from the temporary compression directory if that file exists.

Temporary Directory The temporary directory that IIS uses is configured here. You can either type in the directory name or click Browse and choose it there. The default location is %windir%\IIS Temporary Compressed Files. The temporary directory location must be on the local system, and it must also be on an NTFS partition. It’s also a good idea not to have the directory be compressed with NTFS compression—not that it would hurt anything, but compressing already compressed files doesn’t give you any benefit and wastes CPU time.

Maximum Temporary Directory Size If you wish, you can limit the size of the directory that IIS uses for compressed files. You can estimate how big this directory can get by sizing up all the files for which you have compression enabled. The directory size won’t be any bigger than the size of all the files, and it will probably be less, because they are compressed. If you have the space, there is no need to limit the size. If you do limit size here, when IIS runs out of space in the temporary directory, it automatically makes more space by deleting the files that are used the least. You can choose a value between 1 and 1024 MB.

Other Tabs

The other tabs that are available at the global level are the same as those at the individual web site level. Here’s a description of what is and is not available for each of them.

Web Site Tab At the web site level, the web site identification options are not available, since they set the IP address and port information for the web site. The connection timeout, keep alive, and logging options are all available.

Performance Tab All options are available in the Performance tab.

ISAPI Filters Tab The ISAPI filter options are available. Adding an ISAPI filter here applies to all web sites. You cannot view any ISAPI filters installed here at the individual site level.

Home Directory Tab On the Home Directory tab, you can configure the execute permissions for all sites. You can also enable or disable Read, Write, Directory Browsing, Log Visits, and Index This Resource for all web sites. All of the options available from the Configuration button are active as well.

You cannot configure any application pools at this level. You also cannot set up where the content comes from, since that is very site-specific.

Documents Tab All options are available in the Documents tab.

Directory Security Tab On the Directory Security tab, you can configure authentication and access control for all sites. You can also set up IP address and domain name restrictions for all sites. In place of the Server Certificate wizard is a checkbox called Enable The Windows Directory Service Mapper. This configures Directory Service client certificate mapping, and it is available only at the global level. Directory Service mapping is available only if the web server is a member of an Active Directory domain, and it precludes the use of one-to-one and many-to-one mappings for client certificates. Directory Service mapping stores all the certificates in Active Directory tied to the user account. This way, you need only one certificate mapping for all sites, and you can access resources without supplying a username and password.

HTTP Headers Tab All options are available in the HTTP Headers tab.

Custom Errors Tab All options are available in the Custom Errors tab.