IIS7 RC1 out the door

You may be wondering what I've been doing since the last set of blog posts, which went out shortly after Vista Beta 2 shipped.  Although I'm sure it hasn't kept you up at night, let me reassure you, we've been very, very busy.  :)  With RC1 available for testing, I've re-committed to start blogging again.  The IIS team is now pretty much done with IIS7 in Vista.  We currently have only a handful of real bugs left to fix before Vista is complete, and we've already begun shifting our focus to Longhorn Server (another blog post coming on this). 

**Update** We have now updated the articles on IIS.net to reflect changes made in RC1.  You can see the list of updates in this news post. 

RC1 is a HUGE milestone for IIS7.  We made a big deal out of Beta 2, since it was our official debut in public beta form, but RC1 is a much better build, and much higher quality.  We fixed more than a thousand bugs in RC1, we added a lot of finishing touches on the new Administration UI, and made quite a few finishing touches in other areas of the product.  Some examples include:

  • Improved usability in the UI, including features like "promote Dir/VDir to Application".  There are a ton of small fit-and-finish type improvements to make the UI more usable.  One of my favorites is the ability to right click on any dir/vdir under a site easily 'promote' it to an application.  This is currently limited to directories directly beneath the site (in Server it will be expanded to all levels of the heirarchy) and replaces the old UI semantic of "Create Application" button where you would go to mark a directory as an application. 
  • The UI only shows features that are 'installed'.  So if you don't install the CGI module, you won't see it in the UI.  etc.  This should reduce confusion for administrators who may be trying to configure something in the UI that wasn't installed.  :)
  • Read/Script/Execute settings now apply to handlers configuration.  Remember the old AccessFlags metabase property?  Or do you remember needing to set the "script" execute access to enable ASP/.NET pages to run in the UI?  For a variety of reasons (future blog post here) we've moved them to be an attribute on the <handlers> collection of IIS7.  Look in \windows\system32\inetsrv\config\schema\IIS_schema.xml for the accessPolicy and requireAccess settings for system.Webserver/handlers for more details.
  • System path changes.  We cleaned up the paths IIS uses by default.  Things that really don't belong in the \windows directory are now located under \inetpub, for example:
    • Logfiles now go in \inetpub\logs
    • Temporary compressed files go in \inetpub\temp
    • Custom errors go in \inetpub\custerr
    • and of course, default web site still lives in \inetpub\wwwroot
  • Configuration now uses environment variables by default.  Hard coded paths, be gone!  By default we use the %SystemDrive% variable, since IIS installs here by default, but you can create your own environment variable on the machine - like %webroots%, and then copy configuration across machines and not have to worry about breaking paths.
  • Detailed Errors much improved.  One of my favorite features of IIS7 is the detailed error messages you get on localhost.  We now have the ability to write detailed error information based on the code, subcode, and hresult of the error captured by the server.  With RC1, we added a bunch of new detailed errors, and improved the ones we had.  We also added a "more information" link (and made it configurable so you can point it at your own site if desired) which by default redirects you to an IIS owned site where we will provide up-to-date, detailed error and diagnostic information about the errors you encounter.  Our product support team will be managing the database behind these errors and will be adding more extensive troubleshooting steps over time.
  • Microsoft.Web.Administration improvements.  There are many improvements here, including the ability to now manage SSL configuration, accessing collections, and more.
  • Custom error configuration schema is more self-descriptive.  With beta 2, we had some oddly named attributes for the httpErrors feature, which governs what is sent back to the client when an error occurs.  By default, we send "detailed" custom errors to localhost, including detailed information on the request and things to try in order to fix the error.  We changed the configuration for this to be more self-descriptive: DetailedLocalOnly (default), Detailed, and Custom.  Setting it to "Detailed" will cause us to always send the Detailed error to all clients and setting it to "Custom" will cause us to always send the configured Custom error - to localhost and remote clients. 
  • Minimal footprint.  We removed several components from the default install.  We are truly an "anonymous", "static file only" web server by default.  Add the features you want, only when you need them.
  • Lots of setup work.  We completed our upgrade and sysprep support for Vista.  This was an enormous effort, but for those requiring an in-place upgrade it should work, with a few caveats.  Personally, I never upgrade my machines to a new OS.  I've always found a clean install of the OS, then reinstall of apps, and migration of my own data to be much cleaner.  We'll be publishing a whitepaper on the caveats and issues with upgrading for those who live dangerously. 

We're in the process of updating the technical articles on IIS.net to include these changes, look for them soon.  Grab RC1 today and bang on it hard.  Chances are, what you see in this build is what you will see when the product ships (at least until SP1) so be sure and let us know in the forums if you see anything really ugly.  I think you'll find it to be a much improved version of IIS7 and Vista!

No Comments