IIS 7: Extending Our Extensions Into Your Platforms

eschroed — Sat, 06 Dec 2008 07:06:00 GMT

With the introduction of IIS 7.0 in Windows Server 2008 the game has changed. IIS 7.0 is built using a modular architecture from the ground up. This means two very important things. The first is you only have to install/enable the core set of features YOU want to use, gone are the days of a monolithic design where you had "stuff" running/installed that you simply did not need or use. The same can be said of Windows Server 2008 but that is a post for another time. The second part which is key and brings the most benefit is the module/extension based architecture of IIS 7.0. Currently on IIS 7.0 we ship a handful of in-box modules on top of the core web server engine.

· HTTP Modules (Static Content, Default Document, Directory Browsing and HTTP errors)

· Security Modules (Request Filtering)

· Compression/Performance (Static Content Compression)

· Diagnostics and Health (HTTP logging and Request Monitoring)

· Management (IIS Management Console)

· Windows Process Activation

In addition to the in-box modules that come with IIS 7.0 on Windows Server 2008, the IIS team has teed up, out of box modules that will add new functionality and extend current functionality. All of these modules are available from IIS.NET. These modules fall under the following categories: Content Publishing, Deployment and Migration, Media Serving, Application Hosting, Request Handling, Server Management and Security. These extensions are built upon a new public Integrated Pipeline API which allows modules to be plugged anywhere into the request processing pipeline. The beauty of this design is that we no longer have to wait to ship new features or extend current ones between versions of the core Operating System platform. So in other words gone are the days of old where you the customer had to wait for new version of Windows Server/Client for new functionality in IIS. This makes the IIS 7.0 Web Platform adaptable and nimble to industry trends, empowers us to deliver new functionality for you at greater velocity and allows our customers to build their own modules further extending the platform.

Now that was the history part. Not everyone is going to build their own extensions/modules from scratch and for those that want to there are lots of online resources discussing in greater detail this scenario. A lot of customers use our shipping extensions in their production environments to solve some of their current technology problems or build platforms on top of our platforms. In this post I want to briefly discuss three extensions available today from IIS.NET that are extremely powerful individually but can be leveraged together to build a fairly complex solution for your environment. I will keep this conversation at a high level because I want these examples to stimulate conversation with you our customers as to how you are using these extensions today, where you plan on taking them tomorrow and where do you think we can move them forward.

The three extensions are:

· URL Rewrite

· Application Request Routing

· Web Deployment Tool

At the time of this writing Web Deployment Tool (WDT) is at Beta 2, Application Request Routing (ARR) is at RC (Release Candidate) and URL Rewrite is RTW (Released To Web - Final - Production Ready). They are available in x86 and x64 flavors. I won't go into the specifics or the command sets for each module as they are covered in great detail by the IIS team on IIS.NET, but I will briefly summarize each module's core feature sets.

URL Rewrite is an extension to IIS 7 that provides a rules based engine that uses regular expression pattern matching and wildcard analysis against URLs, server side variables and HTTP headers and can generate back to the requestor custom URLs, Redirects, HTTP Responses or stop HTTP requests based on these patterns.

· Rules-based URL rewriting engine.

· Regular expression pattern matching.

· Wildcard pattern matching.

· Global and distributed rewrite rules.

· Access to server variables and HTTP headers.

· Various rule actions including redirect and request abort.

· Support for IIS kernel mode and user mode output caching.

· Lower case conversion function.

· Rewrite maps to generate the substitution URL during rewriting.

· Failed Request Tracing support.

· Built-in rule templates.

· Integrated user interface for testing regular expression and wildcard patterns.

· Integrated user interface for managing rewrite rules and rewrite maps.

· Integrated user interface for importing of Apache mod_rewrite rules.

Application Request Routing (ARR) is also an extension for IIS 7.0 that leverages the engine in URL Rewrite to provide rules-based routing and load balancing of HTTP/HTTPS requests.

· HTTP based routing decisions built using rules that examine HTTP request information.

· Sophisticated load balancing algorithms to determine appropriate servers to service the HTTP requests.

· Health monitoring for live traffic and specific URLs to determine the health of servers with a set of configuration parameters provided to calibrate baseline server health.

· Client affinity to direct all requests from a client to a specific server by using cookies.

· Host name affinity to streamline administration for Web servers and to create additional business opportunities.

· Management of multiple server farms to enable pilot management and A/B testing scenarios.

· Management and monitoring of all configuration settings and aggregated runtime statistics through IIS Manager interface.

· Support for Failed Request Tracing Rules.

Web Deployment Tool (WDT) is an extension that can be installed on either IIS 6.0 (Windows Server 2003) or IIS 7.0 (Windows Server 2008) and provides simplified migration, management and deployment of Web Servers, Web sites and Web applications.

· Seamless integration into the IIS 7.0 Manager and Visual Studio 10 interface.

· Web server migration and synchronization:

· Ability to synchronize or migrate the entire Web server, a Web site or application.

· Synchronizes only the data that has changed.

· Ability to detect missing dependencies during synchronization.

· Automatically gathers content, IIS Configuration, Certificates and ASP.NET configuration when you sync a Web site.

· Web application packaging:

· Packages a Web application or an entire site, including the associated SQL database.

· Automatically packages ACLs, COM, GAC and Registry settings.

· Supports both live servers and zipped packages as a source or destination.

· Web application deployment:

· Administrative privileges are not required in order to deploy Web applications.

· Integration with the IIS 7.0 Web Management Service (WMSVC) for remote deployment by non-administrators.

· Server administrators have granular control over the operations that can be performed and can delegate tasks to non-administrators.

· In addition to the IIS Manager and Visual Studio 10, tasks can be performed using the command-line, PowerShell cmdlets or public APIs.

Now as I previously mentioned above each of these extensions are fully functional as standalone products within the IIS 7.0 Web Platform. Now imagine that you are an enterprise customer, hoster or even a developer managing a web farm of any scale. As a previous enterprise customer when faced with the age old question do I "Buy vs. Build", I would leverage these extensions to do the heavy lifting for me in the creation of an automated web deployment platform. How you say? There are public APIs that are and will be made available to interact with the extensions so you can glue them together to build your solution for a seamless user experience.

Without getting into the details of what the master console would look like, the base functionality I would want is to deploy content (server, site, application), pull content (server, site, application), and control the flow of traffic (remember we are keeping this basic and leveraging just three extensions for this solution). I would use WDT as the deployment/backup/synchronization engine for my Web Servers, Sites and Applications. It runs as a remote service so I can include WDT as part of my Operating System base build or image. One might even store the packages in SQL so you have a central store for all published content and site/server settings with some versioning control. Depending on the size of the farm I can also have SQL replicas around the globe serving as the package content distribution store. Out of the box WDT provides delegation so you can control what users can deploy and where they can deploy to (they do not have to be an administrator to deploy Web Applications). From my console I can control traffic flow and reroute traffic using ARR and URL Rewrite. I can do rolling upgrades of content using this system and redirect traffic to other servers while content is being refreshed or populated. My users can even use it to move web applications through their lifecycle from DEV/TEST to QA and then Production, whether that be by migrating web applications via WDT to the various server farms or routing some production traffic via ARR and URL Rewrite to DEV/QA staging servers. If I suffer from seasonal effects and need to quickly provision capacity I can leverage my OS deployment system (SCCM, WDS, In-House, 3rd party) or virtual machine management system (SCVMM) to bring nodes online whether that be new physical host deployments or quickly provisioning virtual machines from library and the web deployment system will populate my server settings, site content and/or web applications and start directing traffic to these new nodes. The possibilities are endless.

I would encourage anyone who is not using any of these modules to hop on over to IIS.NET and take a look at what the team has to offer. I would encourage anyone who is using any of the modules today, not just the three I discussed in this blog to leave feedback on the forums. I would personally ask anyone using the three modules above to provide feedback either in the comments section or on the IIS.NET forums.

As for me...well I am a fairly new member of the team. Having recently come to Microsoft back in July 2008 after spending the better part of 14+ years working in the financial services industry in IT. This was my first post on the team site and it won't be my last. I look forward to future constructive two-way dialogue that hopefully come out of these posts.

-eric

Windows Server Customer Engineering : IIS

IIS 7: Extending Our Extensions Into Your Platforms