IIS 7.0: Preview and Expectations 

Before IIS 6.0, the Microsoft Web server platform was pretty straightforward. Early on, it served just static pages and then CGI. When ASP (Active Server Pages) came in, IIS 4.0

was an evolution. IIS 5 and 5.1 simply improved on that capability. Then Nimda and Code Red were unleashed, the two viruses that almost obviated the need for a nuclear World War III. IIS 6.0 was released with lessons learnt from that disaster. This Web server had better security and reportedly needed fewer patches. Most people associate the ASP.NET platform with IIS 6.0, but this is not so-ASP.NET comes out of the .NET Framework and can be readily

disabled in IIS.

So what exactly is it that's going to make IIS 7.0 so much better than its predecessors? After the preview of Vista and the IIS demos given at TechEd, user and developer expectations are certainly high. Let's look at what's been announced so far.

Delegated administration



Even in IIS 6.0, there is a need for the user to be logged on as an administrator-level user to be able to do simple tasks. The shortcut taken around this, an actually major security flaw/risk, is to let Web

developers into the Administrators user group. The task required to be performed may be very simple-restart the website, assign application status to a folder or even add a new field to the server log.

However, in the new version of IIS, the user will no longer need to be an administrator. The IIS console will let the server administrator create a set of users in

participation with the user authenticator (viz the Windows user system) who can then administer websites. Each user can be assigned to multiple websites in a many-to-many relationship. These users would not be administrators of the Windows system itself. This effectively closes that security flaw. But, would this create new problems with IIS's own security?

File-based configuration



IIS 6.0 already opens up the Web server and site configuration file for direct editing, called 'Direct Metabase Editing'. But, this file lives deep within the Windows folder structure and again, Administrator privileges are required to access it-lesser user access will open security loopholes. Incorrect values entered here can also bring down the entire Web server (with lots of sites running on it) and that is bad. 

The alternative is the ASP.NET like approach. ASP.NET uses a three-level configuration approach. The 'machine. config' file, residing deep inside the .NET Framework folder describes the state of the entire server. Then, the 'web.config' file created separately for each website and placed at the root folder of that site describes that one website. The final level is the 'web.config' file in subfolders of

a website that further fine-tunes the configuration of that folder alone. A change in one affects the other in a filter-down effect -for instance, changing 'machine.config' affects all the sites on that server and 'web.config' affects only that particular website or folder depending on where it lies.

IIS 7.0 is slated to use the ASP.NET 'web.config' file to permit Web developers control their site using simple XML 



directives. 

Similar other tags will let the developer load or unload server-modules (see below) to optimize resource usage according to what is needed.

Modular server



IIS is a monolithic entity. Except for the third-party extensions that ride in as ISAPI extensions or .NET modules that sites may load on the fly in its web.config, the rest of IIS is a single entity. For instance, classic ASP and CGI support is a part of the core Web server and even if none of your websites are using it, you still have its code in the memory, leaving an open route for vulnerabilities. You would also be patching all of it every time there's a patch for IIS, even though you're never using that part of the service.

IIS 7.0 fixes that, by shipping as discrete modules. These modules can be controlled by the web.config files by simply adding new keys or removing the ones not needed. Obviously this will require some knowledge about what these modules do, but with proper documentation made available, this can be easy to achieve.

Slipstreamed extensions



ISAPI extensions to the IIS system are cumbersome to write and the means and methods available to the third-party developers are not the same as those used by Microsoft itself. This creates disparity in performance. Also, when the IIS team wants to add a new feature, they add it directly into the core server while the third-party developers do it externally. This is highly unfair.

Reportedly, IIS 7 has a new API architecture, which is tearfully used by all IIS-developers alike to make the extensions. This equalizes performance and opens up the server to custom extensions. This also lets developers do some cool things, like change the way IIS reacts to something-like changing the way directories are listed (where enabled) to a better manner. 



It also lets developers add new extensions they can use and map them to their own handler-engines. This will let developers handle non .NET requests in a .NET module-like authenticating visitors to static HTML or PHP pages with ASP.NET.

Redesigned console



The boring IIS 6 console is gone, replaced by a new one that lets the site and server administrator do a variety of tasks. The configuration is also slated to be more task-related, with all those tabbed

windows gone forever. This, of course, will involve a little running around in the

beginning while the developers and administrators get used to the new way of doing things. 



IIS 7 also tightly integrates the GUI management console with the configuration file in each directory and changes in one are seamlessly reflected in the other.

Application performance tracking



'HTTP 500 — Internal Server Error.' This error that has most Web developers bending knees, and is equivalent to the Windows BSOD. It is next to impossible to figure out why or where the error actually occurred without connecting up to it and step tracing using a debugger. 

Debugging is of course, not possible on a production site (built with 'Release' settings) and test websites may not be identical to production sites, and this creates frustrating downtimes while it is traced and rectified. For instance, the schedules page of the Star TV website (ColdFusion) was down for about two days last month due to a mystery error and the developers spent quite a few hours tracing it down.

In IIS 7, the GUI console lets the site administrator look at the currently running stack of pages and even track it backwards through various page-requests. They can also see what pages are doing what and how much resources they are consuming. This tool is slated to be upgraded prior release to allow the administrator to preemptively shutdown errant (infinitely looping or blocked) pages till fixes are applied.

XCopy deployment



A feature long touted by .NET, is here in IIS as well. Although, for the most part, you can readily copy/paste your websites in all Web servers, including past and

present versions of IIS, the configuration for these websites is what is in the lime light now.

Currently, you have to dive into the Metabase, export the specific keys and tags relevant to the particular site (global configurations further destroying the ease) and re-import it at the remote server. In IIS 7, because the configuration itself resides in the web.config inside the site's folder, all you need to do is copy/paste the entire folder into the desired Web-root and you are done.

At this time



There are no downloadable bits for IIS 7 available yet, and the first releases are expected around PDC later this year, along with the next beta for Windows Vista. IIS 7 major is expected only with the Windows Longhorn Server, the next edition of the Windows Server OS family. 

You can download a preview video and PowerPoint demo of the same from the link in the Direct Hit Box for more

information.

Sujay V Sarma