Exchange SQL And IIS- P155 pps

Chapter 14 Solutions in this chapter: ■ Understanding Development Advantages in IIS 7.0 ■ Extending IIS 7.0 with Native Modules ■ Enabling Managed Code in IIS 7.0 ˛ Summary ˛ Solutions

Chapter 14

Solutions in this chapter:

■ Understanding Development Advantages

in IIS 7.0

■ Extending IIS 7.0 with Native Modules

■ Enabling Managed Code in IIS 7.0

˛ Summary

˛ Solutions Fast Track

˛ Frequently Asked Questions

The Extensible

Core Server

There has never been so much excitement for a Microsoft Web server as there is for IIS 7.0 It is easy

to understand why, when developers across all languages have the same freedoms The parity stopped when a developer using ASP.NET attempted to garner full control of requests incoming to the Web server This freedom wasn’t allowed unless a developer knew C++ and was familiar with the complex Internet Server Application Programming Interfaces (ISAPIs) that were shipped with IIS 1.0 and later versions These rules are changed with IIS 7.0, as developers can choose their languages of choice, and managed code developers have the same access to the same events as their C/C++ counterparts The IIS 7.0 core server hasn’t met a developer it doesn’t like

Understanding Development Advantages

in IIS 7.0

We focus on administration more than development, but one cannot avoid the fact that the landscape for development on IIS has drastically increased with IIS 7.0 Administrators should know that IIS 6.0 and previous versions were in a semi-open system where developers were offered a complex mechanism to modify the behavior of the Web server via ISAPI fi lters In IIS 7.0, that barrier has been broken down and is now open to developers who write both native (C/C++) and managed (VB.NET, C#) code

It is important to understand how native code modules are implemented and installed in IIS 7.0 Beyond that, an administrator needs to understand the implications of introducing managed code into IIS 7.0 and furthermore, how to enable them

Although most administrators typically do not create modules themselves, it is important that they understand from a high level what changes and improvements have been made in the architecture of IIS 7.0, in particular as it applies to developers and the improvements that they will experience

As mentioned in Chapter 12, the core server in IIS 6.0 was monolithic with two request pipelines: one for native modules and another for managed modules The previous platform didn’t provide developers with the environment they desired Developers who used managed code such as C# or VB.NET saw their requests treated as second-class citizens, thereby not having the same freedoms as those who wrote native code such as C/C++ All was not rosy for developers using low-level languages either; they experienced a diffi cult and cumbersome task in extending IIS 6.0

by creating complex ISAPI fi lters and extensions All of this has changed in IIS 7.0

Administrators and developers alike need to understand that IIS 7.0 resolves these issues with a more modular architecture and unifi ed pipeline Whether a developer uses native or managed code, they have full access to the same events IIS 7.0 provides a friendlier place for developers of all types Developers need to know what is involved in extending IIS 7.0 through building native and managed modules, and administrators need to understand the different methods that are available for deploying them

IIS 7.0 supports two different environments brought under the concept of modes Understanding how the two modes apply to application pools and when to use either is important for both

SOME INDEPENDENT ADVICE

The tools provided at Windows Sysinternals are used by many at Microsoft and have been for years, so it made sense when Microsoft acquired the group headed by

Windows guru Mark Russinovich The tools created by this group are some of the

best in the industry What’s even better is that they can be downloaded for free at

www.microsoft.com/technet/sysinternals/default.mspx

administrators and developers The following sections examine each of the concepts mentioned in this section and go through two demonstrations

Inside the Unifi ed Pipeline

In earlier versions of IIS (6.0 and earlier), the development of NET application components was

allowed through ASP.NET This was integrated via ISAPI extensions; therefore, administrators ended

up having two separate pipelines—one for native code (ISAPI fi lters and extensions) and a second for managed code (ASP.NET) Requests to non-ASP.NET content such as static fi les were not visible to ASP.NET under IIS 6.0 and earlier When running in integrated mode, IIS 7.0 allows ASP.NET to

integrate with the core server, thus providing a unifi ed pipeline for both native and managed code

and allowing ASP.NET modules to be used for requesting static fi les and other content No longer do developers have to depend on an ISAPI intermediary, which is diffi cult to write and must be done in

C or C++ Now managed code can control every request going to the application to which it is

mapped Figure 14.1 depicts the core server in IIS 7.0 Notice that both native and managed code

have the same access to the same events

BEST PRACTICES ACCORDING TO MICROSOFT

When you are examining the modules loaded in w3wp.exe, Microsoft

recom-mends using the Windows Sysinternals process explorer Opening up the worker

process in process explorer, developers can examine their modules in action,

whether they are loading or not, and determine the size of their footprint in

memory

Through the use of the new native application programming interfaces (APIs) or ASP.NET, modules can be developed to extend IIS 7.0 Native code itself interacts with the IIS 7.0 request pipeline directly, without any intermediaries or shims The advantage of this is speed and improved performance

Programmers who are used to writing ISAPI fi lters and extensions now have the option of using the new publicly available APIs for creating their new modules These modules allow C and C++ programmers

more freedom because they are not being bound by the tight restrictions in writing ISAPI code

Extensibility in IIS 7.0 is also provided to manage code via webengine.dll As we will see later, this native global module provides managed code direct access to the pipeline when running in integrated mode Isapimodule.dll maps ISAPI calls as though modules were running in the older IIS 6.0 and earlier model in classic mode There will be more about integrated mode versus classic mode later in this chapter

Modules and Kits

Microsoft provides sample modules and starter kits for both administrators and developers of IIS 7.0 Administrators can walk through adding and deleting modules, while developers can use the sample modules as examples for their own These can be downloaded at www.iis.net

Shortcut…

w3svc

Http.sys

Native or Managed Module Handlers Native Handler Managed iHttpHandler Static file Isapi ext *.aspx Trace.axd

Integrated Pipeline

Other native modules Basic auth Digest auth Windows auth

Other managed modules Url auth’z Role mgr Forms auth

End Log Update cache Release state Execute handler Pre -execute handler Acquire state Map handler Resolve cache Authorize begin Native Module iHttpModule

Figure 14.1 IIS 7.0 Core Server

Extending IIS 7.0 with

Native (C\C++) Modules

Microsoft developers changed the way they developed the IIS Web server in IIS 7.0 by ensuring that they used the same APIs that were used by their customers In IIS 7.0, the native APIs used to build features on top of the core server are the same as those used by developers They are built and

enabled the same way, and they are installed similarly

It is important to know how a developer (or administrator) begins building a simple native

module, but much more important to know how to install it correctly in IIS 7.0

C and C++ developers do not have to deal with the diffi culties of writing and debugging ISAPI

fi lters and extensions anymore Developers also do not need to create ISAPI code; anything they need can be accomplished by creating a module As mentioned earlier, native code programmers can use

the new server APIs that Microsoft developers used in developing IIS 7.0 Deployment is also much easier than in the past It is important for administrators to understand how a developer goes through building native modules and what it takes to add them to IIS 7.0

BEST PRACTICES ACCORDING TO MICROSOFT

Before modifying the applicationHost.confi g fi le, Microsoft recommends backing the

fi le up If after adding a native module IIS becomes unstable, it will be easier to

restore to the previous fi le Here is an example of performing such a backup using

AppCmd.exe

Appcmd.exe add backup <name of backup>

SOME INDEPENDENT ADVICE

As an administrator, you may need to add modules on a regular basis If this is the

case, create a naming standard for your backups that makes sense to you You may want to use a naming standard that mentions the module you are about to deploy For instance, if you are about to deploy a module called MyModule, you can put it

in the name of the backup Below is an example of using the module’s name, its

version, and the date This way you know that this backup was done before you

added the module MyModule version 1.0

Appcmd.exe add backup MyModule-1.0-03-1007

Building Native Modules

Although server extensibility can now be done using managed code and the ASP.NET APIs, there

still are reasons developers may want to create modules via native code One of the biggest reasons is