New Security Features
There's big news regarding IIS 7.0's new security capabilities. For the first time, you can create user accounts in the IIS UI! Here's some even bigger news: IIS 7.0 is integrated with .NET Role Providers in Windows Vista and the next Windows Server version, code-named Longhorn. Therefore, the data store for your users can be something other than the local SAM or Active Directory (AD). IIS can authenticate users stored in a Microsoft SQL Server database or any other store for which you have a .NET provider.
IIS 7.0 and .NET integration also means that IIS 7.0 can now offer .NET Forms Authentication as one of its built-in capabilities. Previously available only to .NET applications, Forms Authentication can now be enabled for any programming language that runs on IIS, as well as static content.
Combining the Role Providers with Forms Authentication gives rise to some amazing possibilities. For example, suppose you want to use ASP.NET Forms Authentication to authenticate users of your PHP Hypertext Preprocessor (PHP) application to a DB2 database. No problem. The application requires no special coding to accomplish such a task.
I don't have enough space to mention all the security-related improvements in IIS 7.0, but one of my favorites is request filtering. URLScanstyle filtering capabilities are now built in to the IIS UI.
Troubleshooting and Diagnostics
Server administrators are keenly interested in anything that helps them identify and clarify problems. Wouldn't it be nice to click an application pool and see all executing requests and observe how long they've been running? Your wish is granted.
At any time, you can view the Worker Processes screen (which Figure 4 shows) from within the IIS Manager tool to see a worker process's current memory utilization, CPU use, process ID, and application pool assignment. In the figure, you can see that a pool is consuming too many CPU resources. To see all requests currently running in the worker process assigned to this pool, you can right-click the pool and select View Current Requests. In the example that Figure 5 shows, test.asp is running in Site 1, and it has taken 28,111 milliseconds to process.
If you're familiar with the tracing capabilities that IIS 6.0 Service Pack 1 (SP1) offers, you'll be glad to know that those features are included and extended in IIS 7.0. Tracing in IIS 7.0 (and IIS 6.0 SP1) isn't the same as auditing or tracing in ASP.NET applications. The IIS team has built in hundreds of "events" that you can have recorded in the trace logs.
Enabling and configuring tracing is simple. Simply specify the kind of URL event you want to trigger tracing, as well as the providers you want to report, by writing events to the Failed Event Request logs. For example, you can trace all authentication events related to http://servername/problemapp.aspx, all HTTP 500 errors for any content, or .php events that take more than 10 seconds to execute.
After you configure tracing, IIS will automatically generate trace logs and place them in the \inetpub\faildreqlogfiles\site id number folder. Trace logs are well presented and come preformatted for readability. Event tracing in IIS 7.0 is fully extensible.
Module Magic
Now for the big finish. Typically, to enable and disable features in IIS, you set or clear check boxes or otherwise set properties. In IIS 7.0, you implement features in more than 40 modules. You can load, remove, or replace any of these modules. If you aren't using a feature (e.g., Digest Authentication), you can simply remove it from IIS 7.0 completely, as Figure 6 shows.
Similarly, you can add modules to IIS 7.0 to extend its capabilities. With this functionality, you're able to configure servers that are optimized to do exactly the tasks you require. Also, you can deploy additions to IIS 7.0 that provide entirely new capabilities. For example, you might load a module that would add headers and footers to every page on the Web site. Every page on every site would instantly be affected—without having to modify the original code. Perhaps you would like IIS 7.0 to authenticate to an antique back-end system that has a "unique" authentication protocol. To enable this capability, your developers could write such a module in managed (.NET) or native (C++) code. You could add custom compression, logging, security, monitoring, or any functionality you choose.
You can load modules at the Web server level or per Web site via the web.config file. You can store configuration elements for modules in the web.config file and copy them with the Web content. In this way, a Web site can be fully self-contained with completely portable application code, security principles, Web site structure, and content.
>
MulengaM2006 May 05, 2006 (Article Rating: