If you right-click Application Pools, Web Sites, or an individual Web site and select New, Application Pool (from file); New, Web Site (from file); or New, Virtual Directory (from file), you can create a new application pool, Web site, or virtual directory from a saved file. So, for example, you can create a virtual directory once, use Save Configuration to a File to export the virtual-directory settings, then use New, Virtual Directory (from file) to import the settings into multiple Web sites. In other words, you can create a template configured exactly as you want and use it to create or configure new sites as well as restore settings.
Another advantage of IIS 6.0's new metabase portability is that it makes possible a creative upgrade technique. If you don't want to do an in-place upgrade from Win2K/IIS 5.0 to Windows 2003/IIS 6.0, you need to solve the problem of how to migrate the nonportable metabase from IIS 5.0 to the new IIS 6.0 server. The answer is to create your new Windows 2003 server, make a solid backup of the Win2K server, then upgrade the Win2K server to Windows 2003. You can save the resulting metabase with a password, then import it to the new server. You'll need to make some adjustments to the metabase to allow for the new server's IUSR account and other changes, but at least portability is now possible.
Because IIS 6.0's metabase is a typical text file containing well-formed XML, you can now open and edit the metabase with a text editor such as Notepad. In some cases, when you change the IIS 5.0 or IIS 4.0 metabase, you must restart IIS. Doing so can take a while on systems with many Web sites and can result in significant downtime for servers that have a large metabase, such as an ISP's servers. To address this problem, IIS 6.0 has an edit-while-running feature, which you enable by selecting the Enable Direct Metabase Edit check box in the Properties dialog box for the server in IIS Manager. When the check box is selected, as Figure 3 shows, you can open the metabase with Notepad, paste in a virtual directory, and close the file. IIS 6.0 will pick up the change almost immediately without requiring a restart.
Of course, now that you can edit the metabase directly, you can easily incapacitate your server or application. Thus, Microsoft created the metabase version history folder \system32\inetsrv\history. Every time you make a change to the metabase or restart IIS 6.0, IIS 6.0 makes a backup of the old metabase to the history folder.
Fun with IIS Manager
In any major product upgrade, you expect to find some new cool features in the UI. IIS 6.0's IIS Manager has a couple of changes, but surprisingly few.
One change in the UI is simple but helpful. If you right-click a folder in IIS Manager, you can select Permissions, which opens the folder's Security tab. You can use this tab to change the folder's NTFS permissions without leaving IIS Manager. This feature will save a few thousand work hours this year worldwide.
Another change involves the property page that's displayed when you right-click a Web site, select Properties, go to the Directory Security tab, and click Edit under Secure Communications. You use the Secure Communications property page to configure SSL, certificate trust lists (CTLs), and client certificates. In IIS 5.0 and IIS 4.0, you can't access this property page unless you've installed a certificate on the Web site. This restriction is interesting because configuring CTLs and client certificates technically doesn't require a certificate installed on the server. In other words, the only reason you need a certificate to use these features in IIS 5.0 is that the UI requires it. IIS 6.0 fixes this incongruity—you can access the property page and use its features without having to install a certificate on the Web site.
Allowing access to CTLs and client certificates without requiring a Web site certificate fixes one problem but causes another. The Secure Communications property page lets you enable the Require secure channel (SSL) feature. However, because you don't need a certificate to reach this page in IIS 6.0, you could set a Web site or directory to require SSL even though the Web site isn't SSL-enabled. If you do so, users will receive the message 403.4 Forbidden: SSL is required to view this resource. Don't be fooled into thinking that your ability to enable the Require secure channel (SSL) setting for a Web site or directory means that that Web site or directory can negotiate SSL.
ISAPI Interceptors
Those of you familiar with IIS 5.0's and IIS 4.0's Internet Server API (ISAPI) filters might also be familiar with their shortcomings. They're difficult to build, and because they run in the Inetinfo process, making mistakes when building them can cause disasters. An ISAPI filter that has an exception that buggy code caused can halt IIS. In addition, ISAPI filters don't have all the capabilities of regular ISAPI DLLs. Nevertheless, ISAPI filters are useful because they're the only mechanism in IIS 5.0 and IIS 4.0 that can run code that you want to run against all traffic coming to the Web server or a Web site.
IIS 6.0 offers a new, more flexible mechanism known as ISAPI interceptors—also called wildcard applications—to provide services that ISAPI filters often deliver. You can configure these applications by right-clicking Web Sites in IIS Manager, selecting Properties, going to the Home Directory tab, then clicking Configuration. On the Mappings tab of the resulting Application Configuration dialog box, which Figure 4 shows, you can insert one or more ISAPI DLLs as wildcard applications. IIS 6.0 will invoke these applications for every request it receives. You can also configure these settings at the individual Web site or directory level. Because these ISAPI interceptors are typical ISAPI applications, they have the full range of capabilities that any ISAPI application has, including access to message bodies, not just the headers that ISAPI filters have access to.
A wildcard application can do whatever the developer wants it to do, including URL customization, authentication, specialized logging, intrusion detection, and content creation. When the wildcard application completes its processing, it hands off the request to the intended processing engine (such as asp.dll for an ASP page), which then processes the request. The wildcard application could also redirect the traffic to any page in the same application pool by invoking the new ExecuteURL capability available to ISAPI applications.
This new ISAPI interceptor capability opens several doors for creative application design. For example, IIS 6.0 implements its new URL authorization capabilities as the ISAPI interceptor urlauth.dll. URL authorization lets IIS 6.0 authorize access to a URL based on rules such as group membership, state of residence, or any other attribute associated with the user in a database or in AD. For more information about ISAPI interceptors and URL authorization, see the IIS 6.0 Help files.
Prev. page
1
[2]
3
4
next page 
