Internet Information Services 7
Like several other major subsystems in Windows Server 2008, Internet Information Services 7.0 (IIS7) has undergone a major overhaul and now looks set to compete with the open-source Apache web server on a more equal footing. Indeed, some would say that IIS7 has borrowed a number of ideas from Apache and built upon them. For example, IIS7 web sites can now be created simply by copying an XML file into the appropriate directory on the server. As you'd expect, those sites can be reconfigured simply by editing that XML file, and could be remotely deployed using the new robocopy command (short for 'robust copy'), which works with network connections and replaces the now-deprecated xcopy.
Support for the open-source PHP server-side scripting language has been improved, and can be used with Server Core configurations to make an attractive server configuration for some web-hosting organisations.
Testing by ZDNet.com.au's sister site ZDNet UK used the Add Server Role wizard to configure a Windows Server 2008 system to run IIS7. We used the default installation options, which added most of the components that organisations would need to host basic web sites.
There are many options for configuring IIS7, but most tasks can be accomplished using the IIS Manager GUI, or with the new command-line tool called appcmd.exe. PowerShell scripts can also be used for this kind of work, so we installed Windows PowerShell using the Add Features Wizard and tested it by running a simple script to create some web sites in our IIS hierarchy. We launched the PowerShell command-line interface using a link in the All Programs section of the Windows Start menu. By default PowerShell is configured only to run scripts that have been digitally signed, and as our script was unsigned we needed to adjust the PowerShell execution policy of our test system to allow our scripts to run. In production environments, server administrators may prefer to maintain the default setting.
We could then run our PowerShell script to create web sites rather than creating them using the Windows GUI. The script took just over two minutes to create and start 10,000 sites on our test system. A production server fitted with more disks would probably complete the task much quicker. We made a video walkthrough showing the script creating 1,000 sites, which took about 16 seconds to complete.
Existing ASP.NET web sites running on IIS6 servers will run without modification, but IIS7 has a new 'Integrated' mode that's only available to sites that have been migrated to IIS7's ASP.NET. There are command-line tools to convert older sites so they run properly using the new Integrated mode, and most people are likely to use them to convert their sites to gain access to the superior features available.
To test some PHP web sites, we also downloaded the latest version of the open-source PHP software from www.php.net. We wanted to use ISAPI to handle PHP requests, so we needed to add ISAPI support to our IIS configuration, which was easily done by clicking on the Add Role Services link in the IIS section of Server Manager.
Installing PHP into IIS7 is a quick and easy process -- it took us about 15 minutes. First we created a PHP folder in the Inetpub directory and decompressed the PHP binaries into it. Then we created a php.ini file using the contents of php.ini-recommended (which comes with the PHP binaries) and configured a handler for PHP document requests using Inetpub\php\php5isapi.dll. Having selected our server in the IIS Manager GUI, we double-clicked on the Handler Mappings applet to create the appropriate mapping. We could also have used Inetpub\php\php-cgi.exe.
At this point we simply copied a directory containing a PHP web site into the IIS webroot directory and used the IIS Manager GUI to create a new web site. We could then connect to the site using a browser on our server.
Creating a Handler Mapping for PHP document requests in the IIS Manager.
appcmd add backup zdnet-test
Next we deleted our PHP web site from the IIS Manager hierarchy, and restored the backup facility using the following command:
appcmd restore backup zdnet-test
The Automatic Failed Request Trace Logging module is another useful new feature. As its name suggests, it watches for specific errors and logs them to a file. To use this feature we needed to add ASP.NET and Tracing Role Services to our IIS configuration using the Add Role Services link in the IIS section of Server Manager, and restart IIS Manager. We could then enable the module on our sites by highlighting them in the IIS Manager hierarchy and selecting the Failed Request Tracing link in the right-hand action panel.
The Automatic Failed Request Trace Logging module watches for specific errors and logs them to a file.
Next we used IIS Manager to create a Failed Request Tracing Rule for our site. We found the process of configuring IIS to log details of requests so easy that we didn't need to consult documentation. We created a rule to log details of requests that resulted in an HTTP status code of 404, which would cause the module to log details of requests for pages that could not be found, and tested our rule by browsing to a page that did not exist. Because we were using IIS7's enhanced error-reporting capability, which is enabled in default configurations, a fairly informative error report was returned to the browser rather than the terse 404 page that some web servers might offer. More impressive still was the vast amount of detail contained in the log file produced by the FRTL module, which was also formatted for easy viewing in a web browser. The information here enabled us to trace through each module used to handle our request and identify exactly why the request failed.
We created a Failed Request Tracing Rule that gave informative error reports on non-existent web pages thanks to IIS7's enhanced error-reporting capability.
Rather than watch for a specified status code, the FRTL module could be configured to watch for requests that took more than a specified amount of time to complete. The time value used must be an integer, but otherwise is arbitrary, so IT staff could use longer or shorter times depending on the behaviour of the application they are working with. FRTL could also be configured to log events according to the severity of the error message, for example, so it logged only 'critical errors'.
IIS7 is packed full of new features that will make it easier to run multiple web sites on a single server. In this review we've only been able to scratch the surface of what's becoming an excellent platform for corporate web applications.
2%
4%
Be very careful of building applications based on M$ servers... Server 2003 dropped support for earlier API calls, and our application failed to work... The problem was that with M$ you can't really stay on older versions, as support is dropped etc, yet there is no corporate commitment to retain reverse compatibility. It would not have hurt M$ to retain the API support... but M$ just thought everyone should be migrated onto the newer M$ ways of doing things (.NET etc further lock-in). Our problem was that we were not yet ready to re-write that functionality.. and the programers who did write the earlier stuff were no longer around. To this day, for adding new users to an M$ Access application, we need to copy the database off the 2003 server back to the prior server (NT server) and make the changes, then re-copy the database files back onto the 2003 server. Clearly the application still works, but what changed was M$' support for functions done within their own complementary products (eg Access).
The good: Can't think of any... Presumably some of the security problems of the earlier product are addressed... but at a cost of greater lock-in.
The bad: Our experience with non-compatibility in 'upgrading' from one M$ product to its replacement has meant that we are seriously looking to standardise on only Linux servers, knowing that Linux retains strict reverse-computability and adherence to true standards.